更新了！深入浅出图解Git，入门到精通（保姆级教程）第三篇( 二 ) 原文链接：这一篇写完基本Git的操作就

此时Tom更新分支后，本地的分支情况如下所致，相比原来master指向c1 ，现在向前推进了一个版本指向c4：
文章插图
此时， Tom必须重新合并分支进行提交，把branch的代码合并到master分支上，现在Tom可以有两种方式：

直接git merge 。
先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的使用命令也是非常的简单。