原文链接：https://mp.weixin.qq.com/s/d7YwRi1mEkxUSUqxWD_B1Q

这一篇写完基本Git的操作就图解完了，如果想深入了解Git，这里可以推荐一些Git的硬核书籍：【精通Git】、【GitHub入门与实践】、【Git权威指南】、【Git版本控制管理】、【GitHub实践】。

这些都是一些关于Git的比较好的书籍，有兴趣的可以可看一看，网上也有很多电子书。闲话不多说，下面就开始我们的正题。

日志

Git查看日志前面有提到过可以通过git log命令进行查看：

git log可以查看你「提交的时间、提交的作者、以及提交的id」都可以查到，如果你觉得查询的信息太多，可以加上参数--pretty=oneline，只会显示版本号和提交时的备注信息。

如果你想查最近的几条历史记录，可以通过加参数"-n"的形式制定查询几条记录，历史记录是「按照操作的时间」进行排序的：

还可以通过加参数" --graph"，以图形化的形式展示历史记录，方便与查看历史记录与分支的关系：

还可以加参数"-p"，可以查看每一个commit操作更改的文件的哪一行，加参数"-stat"查看哪些文件改动了，进行简要的统计。更加详细的git log参数可以查看命令帮助。

Git查看历史记录的另一个命令是git reflog，它可以查看「所有分支的所有操作记录，包括已经删除的commit记录和reset记录」。

衍合(rebase)

分支管理中有「合并」和「衍合」操作，合并操作在在第二年篇的分支章节已经详细讲解过了，就来讲解一下衍合操作：git rebase操作。

假如有两位开发人员Tom和Jerry，Tom和Jerry都把远程的master分支签出到本地，此时当前的Tom和Jerry本地都是只有一条master分支：

此时Tom开发人员，创建一条新的分支branch，并且将新的分支branch推向远程仓库(git push origin branch)：

此时Tom本地仓库和远程仓库的分支保持一致，分支如下图所示：

Tom在自己的分支branch上开发自己的模块，假如开发期间Tom进行了「两次」的提交，最后Tom本地的分支形成如下所示：

也可以通过git log查看两次提交的记录：

若是，此时Tom开发人员准备把自己的branch的分支推向远程仓库，但是，Jerry在此之前已经在master提交了自己的开发代码，所以master分支相比之前记录，已经向前推进了一个版本。

所以此时Tom想提交，必须先更新一下自己的本地分支：

Tom中通过git log命令可以查看到Jerry的提交记录情况，说明此时分支已经与远程仓库同步：

此时Tom更新分支后，本地的分支情况如下所致，相比原来master指向c1，现在向前推进了一个版本指向c4：

此时，Tom必须重新合并分支进行提交，把branch的代码合并到master分支上，现在Tom可以有两种方式：

1. 直接git merge。
2. 先git rebase，然后git merge。

(1)若是使用第一种方法直接在master分支上执行git merge命令，「Git会把master分支上最新的提交c4的内容和branch分支上最新的提交c3 合并后生成一个新的提交点c5」：

上面实在没有冲突的前提下，若是有冲突，则解决冲突：

此时就完成了master和branch分支的合并。

(2)若是使用第二个方法，先master也需要拉取到最新版本，然后是切换到branch分支，这个也就是要切换到rebase的分支，这里指的是branch分支。

在branch分支执行git rebase master，表示chanch上新提交的c4节点会在master上的最新提交点后重新设立起点重新执行，若是有冲突则解决冲突，没有冲突执行git add，最后执行git rebase --continue。

通过git log查看你可以发现，之前branch分支上进行【「删除HELLO ABC」】的操作commit hash已经发生改变，最后切换到master分支，执行git merge master。

通过测试可以发现，原来branch分支上重新commit的节点c4在rebase到master分支后hash发生了改变，并且提交的内容被复制保留，从而使得master分支整个呈现线性的commit记录，而不是直接git merge后的分叉记录。

在master分支进行branch分支rebase的原理图如下：

注意：「一般不是在branch进行rebase主分支master的提交，因为会导致master的新提交在本地丢失，这样有可能会导致本地仓库与远程仓库发生冲突，从而无法push操作」。

「总结」：「git merge会将两个分支的最新提交点进行一次合并，形成一个新的提交点，最终形成树状的提交记录」，但是有些人并不是喜欢merge，觉得merge之后出现的分叉会难以管理，那么可以选择rebase操作来替代merge。

「git rebase操作是将要rebase的分支最新提交点作为新的基础点，将当前执行git rebase master的分支的新commit点重新生成commit hash值，rebase完后再次切换到另一条分支进行合并，就可以保证线性的commit的记录」。

「最后只选择merge还是rebase取决于个人和实际情况，假如你想提交记录呈现线性整洁那么选择rebase，否则选择merge，实际情况也有可能是这样的，每个人本地开发，可能会提交非常的多次，有些提交可能是修一些简单的bug，那么最后的提交只想做一次完整、正确的提交，那么也可以使用rebase。」

标签管理

Git中使用的标签有两种类型：「轻量级的(lightweight)和含附注的(annotated)」。轻量级标签只需在git tag后加上标签的名字，就可以添加标签。

标签管理作为开发人员可能很少使用，可以作为了解，「tag是针对Git中某一时间某一版本打上标签」，tag的使用命令也是非常的简单。

新建标签

新建一个标签，默认是在HEAD新建，可以指定commit id新建，具体命令如下所示：

$ git tag $ git tag  $ git tag -a  -m "备注"

删除标签

删除标签若是标签没有推向远程仓库，直接使用以下命令删除：

$ git tag -d 

若是标签已经推向远程仓库，先删除本地，再删除远程仓库的标签：

$ git tag -d $ git push origin :refs/tags/

查看标签

git tag的方式是查看所有的标签，git show 的方式是查看每个特定的标签

$ git tag$ git show 

推送标签到远程

推送标签也是分两种情况，一种是指定标签的推送，另一种是推送所有标签。

$ git push origin $ git push origin --tags

提交了错误代码

代码错误提交了怎么办，重新再一次提交一个版本呗，这个可能是很多人的解决方案，当然Git也是有提供自己的解决方案的命令。

第一种就是再次将修改文件然后git add .到暂存区，最后git commit --amend提交修改 ，它的原理图如下所示：

这种方法只能修改当前HEAD，也就是最新的提交，那么要修改是倒数第二个或者倒数第三个的提交呢？

这时候就要使用rebase -i(「交互式rebase」)进行操作了，这个命令是指定commit链中哪一个commit需要修改。

比如执行命令：git rebase -i HEAD^。它表示的含义就是把当前commit内容rebase到HEAD之前的一个commit上。

若是想直接丢弃最新的commit的修改，则直接使用命令：git reset --hard HEAD^。他表示当前commit往前移动一次。

那想丢弃某一次的修改呢？并不是最新的commit，通用也是要使用rebase的交互式操作：git rebase -onto HEAD^^ HEAD^ master。他表示的含义就是以倒数第二个为起点，master为终点，rebase到倒数第三个commit上。