一、git commit提交之后，发现有错误怎么办？

当commit之后发现代码有错，简单直接的方法就是进行修改代码，然后第二次commit。

这样git log可以看到两次commit的信息

其他思路

如果你commit了之后还没有推到远程仓库，commit信息还在本地，此时可以根据git log的hashid来重置commit版本信息。

git reset

git reset –mixed

此为默认方式，不带任何参数的git reset，即时这种方式，它回退到某个版本，只保留源码，回退commit和index信息

git reset –soft

回退到某个版本，只回退了commit的信息，不会恢复到index file一级。如果还要提交，直接commit即可

git reset –hard

彻底回退到某个版本，本地的源码也会变为上一个版本的内容

修改备注信息

git commit -amend

二、怎么在项目开始/项目中正确的添加忽略文件或目录？

忽略文件

git rm与git rm --cache的区别

当我们需要删除暂存区或分支上的文件, 同时工作区也不需要这个文件了, 可以使用

git rm file_path

git commit -m 'delete somefile'

git push

当我们需要删除暂存区或分支上的文件, 但本地又需要使用, 只是不希望这个文件被版本控制, 可以使用

git rm --cached file_path

git commit -m 'delete remote somefile'

git push

忽略一个已经被跟踪的目录（再也不管它了）：

git rm -r --cached dir

echo dir/ >> .gitignore

git add .gitignore

git commit -am 'ignore dir forever'

三、怎么给git命令创建快捷方式？

git alias

第一种方法：

git status

可以设置为

通过配置git本身，

git config --global alias.s status

从此，git s就是git status

第二种方法:

vim ~/.gitconfig

第三种方法;

vi ~/zssrc

配置系统的别名

四、git stash是什么？

git stash 可用来暂存当前正在进行的工作， 比如想pull 最新代码， 又不想加新commit， 或者另外一种情况，为了fix 一个紧急的bug, 先stash, 使返回到自己上一个commit, 改完bug之后再stash pop, 继续原来的工作。

基础命令

$git stash

$do some work

$git stash pop

进阶

git stash save "work in progress for foo feature"

当你多次使用’git stash’命令后，你的栈里将充满了未提交的代码，这时候你会对将哪个版本应用回来有些困惑，

’git stash list’ 命令可以将当前的Git栈信息打印出来，你只需要将找到对应的版本号，例如使用’git stash apply stash@{1}’就可以将你指定版本号为stash@{1}的工作取出来，当你将所有的栈都应用回来的时候，可以使用’git stash clear’来将栈清空。

git stash # save uncommitted changes

pull, edit, etc.

git stash list # list stashed changes in this git

git show stash@{0} # see the last stash

git stash pop # apply last stash and remove it from the list

git stash --help # for more info

五、git rebase是什么？

rebase 的概念/作用其实很简单——就是「变基」。具体来说，就是改变一条分支的「基点」，使原分支从指定的地方（commit）重新长出来。并且，由于是一条新分支，你可以随意修改其中的 commits，也就是——重写分支历史。

而 rebase 的主要目的即删繁就简。

下面讲下关键步骤：

git rebase [-i | --interactive] [options] [--exec ] [--onto ] [ []]

git rebase [-i | --interactive] [options] [--exec ] [--onto ] --root []

git rebase --continue | --skip | --abort | --edit-todo

所有 rebase 的操作对象都是 commit。（你可以 rebase 一个分支 git rebase -i branchX，但实际上还是作用于该分支最新的 commit。）

以这个 commit 为「新基点」发起 rebase 后，会打印出一篇 commit 历史让你修改。

其中最常用的修改就是把 commit 前的 pick 改为 s (squash, /skwɔʃ/, 意为挤压)，作用为保留该 commit 作出的修改，但删去该节点，只给它一个留名的机会。(用专业的话讲就是——不保留待合并分支上的历史信息，也不提交、不移动HEAD。）多个以 s 为前缀的 commit 最终会整合成一个 commit，各个 commit 的描述部分也被整合到一起。

而最终极的修改就是直接删去 commit(s) ——篡改历史。这也就意味着，对应的改动也一并灰飞烟灭。（所以为什么说 rebase 是个危险的操作，就是因为篡改了历史！想想如果别人基于你国正史 fork 了一条分支，而你日后竟变基了会发生什么吧！）

改完之后 :x（Vim下的保存退出命令），Git 就去检测冲突了，此时类似于合并。

合并将按你留下的 commit(s) 重演历史，你可以修改每一次 commit 的具体代码。而如果你不是为了修改，只是为了简化树……我的办法是只留下一条 commit，用最新工程完全覆盖来解决冲突。（不知有没有更好的方法）

冲突解决完后 git rebase --continue，你就可以正式「书写」历史啦——撰写新的 commit 描述。这时那真是，想怎么写就怎么写~

这般本地 rebase 完成后，记得 git push -f，-f 用于强制将新历史推送至远程仓库。

至此，rebase 就彻底结束了。

看看你新造的树吧，是不是特简洁，特优美？（如果不是……你 rebase 干嘛……）

当一个系统的专有名词（黑话）足够多，就创造了文化。

在贡献开源代码时，git rebase可以直接把log同步过来，而不会有 git merge 的log。

怎么打标签，打标签有啥用？

打标签

同大多数 VCS 一样，Git 也可以对某一时间点上的版本打上标签。人们在发布某个软件版本（比如 v1.0 等等）的时候，经常这么做。本节我们一起来学习如何列出所有可用的标签，如何新建标签，以及各种不同类型标签之间的差别。

列出已有的标签

列出现有标签的命令非常简单，直接运行 git tag 即可：

git tag

v0.1

v1.3

显示的标签按字母顺序排列，所以标签的先后并不表示重要程度的轻重。

我们可以用特定的搜索模式列出符合条件的标签。在 Git 自身项目仓库中，有着超过 240 个标签，如果你只对 1.4.2 系列的版本感兴趣，可以运行下面的命令：

git tag -l 'v1.4.2.*'

v1.4.2.1

v1.4.2.2

v1.4.2.3

v1.4.2.4

新建标签

Git 使用的标签有两种类型：轻量级的（lightweight）和含附注的（annotated）。轻量级标签就像是个不会变化的分支，实际上它就是个指向特定提交对象的引用。而含附注标签，实际上是存储在仓库中的一个独立对象，它有自身的校验和信息，包含着标签的名字，电子邮件地址和日期，以及标签说明，标签本身也允许使用 GNU Privacy Guard (GPG) 来签署或验证。一般我们都建议使用含附注型的标签，以便保留相关信息；当然，如果只是临时性加注标签，或者不需要旁注额外信息，用轻量级标签也没问题。

含附注的标签

创建一个含附注类型的标签非常简单，用 -a （译注：取 annotated 的首字母）指定标签名字即可：

git tag -a v1.4 -m 'my version 1.4'

git tag

v0.1

v1.3

v1.4

而 -m 选项则指定了对应的标签说明，Git 会将此说明一同保存在标签对象中。如果没有给出该选项，Git 会启动文本编辑软件供你输入标签说明。

可以使用 git show 命令查看相应标签的版本信息，并连同显示打标签时的提交对象。

git show push_v1.2

tag push_v1.2

Tagger: machuang 780@qq.com

Date: Sun Sep 10 12:06:50 2017 +0800

version 1.2 project coding end at 2017-8-23.

This tag create at 2017-9-10

s

commit f1759f45b598611231d9e768

Merge: f8f4 saf9

Author: XScarletAngel 7369@qq.com

Date: Wed Aug 23 18:30:27 2017 +0800

Merge branch 'branch1.2' of git.du.com:admin/admin into branch1.2

• 'branch1.2' of git.du.com:admin/admin:

Test

我们可以看到在提交对象信息上面，列出了此标签的提交者和提交时间，以及相应的标签说明。

根据commitid打标签

git tag -a <tag名> <commit对应的hash码>

tag推送到远程仓库

默认情况下，git push并不会把tag标签传送到远端服务器上，只有通过显式命令才能分享标签到远端仓库。

1.push单个tag，命令格式为：git push origin [tagname]

例如：

git push origin v1.0 #将本地v1.0的tag推送到远端服务器

2.push所有tag，命令格式为：git push [origin] --tags

例如：

git push --tags

或

git push origin --tags

以上命令经检验通过，如果不起作用，请在Git控制台上确认你的账号是否有权限推送Tag。

推荐一本电子书

https://www.kancloud.cn/martist/ma_zhao_li...

本作品采用《CC 协议》，转载必须注明作者和本文链接