理解git结构与简单操作（四）合并分支的方法与策略

接上节，此时的dev分支与master分支的进度就不一样了，所以需要将dev分支与master分支同步。这里需要的就是合并分支的操作，大家应该都知道用git merge或者git rebase。

git merge

merge，即「合并」。

fast-forward

当出现我们上面图中的那种情况时，时间线只有一条，dev分支只不过是落后master分支而已。此时我们在dev分支上执行git merge maseter时，git就仅仅会把dev分支指针移动到master分支所在的位置，假装合并了，就变成了这样：

这种merge的方式叫做「fast-forward」，也是git默认的merge方式。

如果情况改变了，举个例子：我们在开发过程中，一直使用的是master分支，这时出了一个很严重的bug，我们就需要建立一个叫topic的分支来处理这个bug，但主要的功能工期又不能拖，所以master分支与topic分支就同时向前推进，此时时间线如图所示：

(此图出自git自己的帮助文件，使用命令git help merge即可看到。想看其他命令的帮助就git help <command>即可)：

这时候，topic上的bug修改完毕，需要合并回master分支，需要的操作为：切换到master分支git checkout master，合并devgit merge dev。

注意，这时候的这两条分支是真正的「分支」了，他们在时间线上岔开了，各自分支都有自己独有的东西。

因为此时的topic分支的末端并不在master分支的父端，需要把不同的修改同步起来，单纯的指针移动不能完成这一步，fast-forward方式也就不可能实现了。

这时，git便会将两个分支不同的地方取出，合并成一个commit，然后把master指针指向这个新的commit（就是在master上生成了一次commit）。这样，topic分支上的修改就同步到master分支上了。此时分支情况如图：

no fast-forward

BTW，能够进行fast-forward的merge情况下，也可以通过增加--no-ff命令来强制不使用fast-forward模式。假如还是回到我们master-dev两个分支的例子，master领先于dev分支：

这时我们不用fast-forward，在落后的dev分支上执行git merge master --no-ff，git会在dev上强行创建一个commit，把master分支上不同于dev的修改加进去，分支线就会变成这种诡异的样子：

（本手残渣画图实在是不好看，就直接用GUI工具source tree上的情况截图了）

底层上，git会把将要合并的两个分支的各个commit快照进行差异比较，求出它们之间的最长公共子序列，并把公共子序列从中去掉，得出各自存在两个分支中的不同修改，并将其合并成一个commit放在当前分支的顶端。

这里仅仅说明一点原理，具体实现方式与算法本人也只是懂一点皮毛，只要明白fast-forward与不使用的情况下merge，分支会产生什么样的情况，用来工作就没有任何问题了。

squash

除了--no-ff，merge还有另一种合并的方式：--squash。这种方法在符合fast-forward的情况下依然会执行fast-forward方式，不会有任何改变。但当遇到如下情况时：

假设我们要将topic合并到master上来，squash方式会集中topic的「A、B、C」三次commit中的修改合并，并添加到暂存区中。

这时master分支与topic分支不会有任何的变动，只不过暂存区中会被添加topic上修改的集合（暂存区=A+B+C）。

这时我们就可以查看暂存区中的内容是不是符合一次提交，之后commit就可以了。git help merge里是这么描述的：「create a single commit instead of doing a merge」，结合上面的讲解就可以理解squash的意思了吧。

git merge 解决冲突

fast-forward中是没有冲突的（不明白为啥没冲突的面壁思过）。而在其他情况时，如果两个分支同时有对同一个文件（行）的修改，就会产生冲突。这时git会在产生冲突的文件里写一堆这样的东西：

上面的「<<<<<<<< HEAD」直到「========」的部分，就是当前分支的修改（看到HEAD就知道是指向当前分支的指针了）。而「========」到下面的「>>>>>>> dev」的部分自然就是dev分支合并过来的修改啦。

这时需要你仔细对比冲突，如果跟同事合作的话就要商量好，然后把「<<<<< HEAD ===== >>>>> dev」之类git给你加上的东西和不需要的修改部分删掉。接下来git status就会看到下面的提示：

上面绿的的东西自然就在暂存区了，这些代表dev分支上并不冲突的部分。下面的红色文件就代表你冲突的文件，当你修改之后需要走一遍add -> commit的流程（这个commit可以不指定commit message），也可以直接执行git commit -a，就完成merge创建新commit的过程了。

涉及操作：git merge <branch>, git merge <branch> --no-ff, git merge <branch> --squash, git checkout <branch>, git help <command>

git rebase

除了merge，git还有一种分支合并的方式，叫做git rebase。

rebase，就是「re」与「base」结合，官方译名「变基」（咖喱gaygayʕ •ᴥ•ʔ）。这个「变基」的含义从字面上确实不是很好理解，先来看一下rebase示例：

回到我们master-dev两个分支的例子，master领先于dev分支：

这时候我们在dev分支上执行git rebase master，master便与dev合并了，如图所示：

此时你内心OS：这不是跟fast-forward模式下的merge一样么？莫急莫急，我们再看一下出现这样情况下的分支（作者偷懒拿前面图糊弄了嘿嘿嘿）：

不着急解释原理，我们先看看在topic上执行git rebase master的结果（就是将master合并到topic上）：

看图得知：master上的「F」「G」两次提交，变成了topic分支的父节点，整个分支又重新合成为一条时间线。在本例中，你可以想象「biu」的一下把topic分支拔下来，然后「pu」的一下把它插到了master的顶端（大雾）。

当然，git肯定不是像上面那样「biu」「pu」地操作分支的。

git help rebase中是这样描述git rebase的：

git-rebase - Reapply commits on top of another base tip

翻译一下，就是「将你的commit们在另一个基准点上重新应用」。注意这里的「reapply」，git并不会直接移动commit本身，而是会为需要rebase的分支上的commit分别创建一个patch「补丁」，然后将patch在基准点上依次应用，重建出一条时间线。

可以参照上面的两张图梳理一下流程：

当我们在topic分支上执行git rebase master时，代表了我们要将我们当前的分支（topic）应用到指定的master分支上。

此时topic与master的共同父节点是「E」，topic的特有commit是「A」「B」「C」，git就会按照时间点，分别创建「A」「B」「C」的patch「A'」「B'」「C'」，然后将topic分支的基准点设置为master分支的顶点「G」（「变基」了！），依次将「A'」「B'」「C'」Apply到「G」上。

现在是不是理解「rebase变基」是什么意思了！

git rebase 解决冲突

rebase产生的冲突与merge其实是相同的。但由于rebase操作会按照patch一个个打补丁上去，每打一个都有可能会产生冲突，跟merge的产生一个commit这种一次性操作不一样，解决冲突之后也就不是提交commit，而是git add <file>之后执行git rebase --continue。

也就是「打一个补丁，解决一次冲突，然后继续下一个补丁」的过程。

如果你不耐烦了，也可以git rebase --abort直接不进行rebase了。

涉及操作：git rebase <branch>, git rebase <branch> --onto <commit id>, git rebase --continue, git rebase --abort

关于分支处理策略的选择

上面讲了好多关于分支的东西，可能会让人困惑：分支涉及到的东西这么多，本身又复杂，多分支处理也复杂，应该怎样利用分支才好？分支合并的策略选哪一种呢？这里我说一下个人的见解：

首先，git保存的是修改这一点，可以很清楚的让我们知道代码发生了哪些改变。在这样的情况下，我们利用commit时间线就可以明确地区分哪个人在什么时间做了什么事情，也就是给了你「查看历史」与「修改历史」的权力，这对一个软件项目来说是至关重要的。

有关git多个分支的设计，其实是非常巧妙的。多个分支解决了以代码本身不同版本、不同功能或不同目的的开发方向（比如开发新功能或改bug，又暂时不想修改主要版本）开发时的代码版本管理问题，能够很方便地管理工作区的文件内容。

所以，我对多分支系统利用的理解是这样的：

分支是需要充分利用的。首先要确定一个master分支，作为这个项目最终上线的版本，要保证合并到master分支上的代码都是确定无误的、测试通过的。
在开发过程中，可以使用一个development分支来开发，用其部署测试环境，使这个分支成为可以随意修改的分支，增加开发的灵活度。
在master或者dev分支出现问题，或者要分头行动时，为每个分支在合适的父节点上创建新的功能分支或bug分支来处理这些问题，可以保证主要的代码不会出错，就算是开发出问题，直接删除该分支便是，基本不用涉及到文件层面的修改。
所以，对工作区的修改应该仅限于增加新内容和修复bug之类的操作，其他的都应该交给git去处理，保证版本树是一条路，复杂的功能删除也不用一行一行找。
当某个分支的某些commit出现问题时，可以先将没有问题的部分建立分支保存起来，保证那些内容不会出问题。

有关git代码合并策略的选择，虽然git提供了非常丰富的方法，但一个team使用的方法应该大体固定成同一个，这样能避免很多混乱，然后在适当的时机使用不同的策略。在《Pro Git》这本书中总结的就很好，我摘下来总结下：

选择merge还是rebase取决于你对commit历史时间线的定义。
有两种观点：第一种认为，commit历史应该显示的是什么时候具体发生了什么事，比如分支的创建与合并过程，有哪些分支，分别合并在了什么地方等等。另一种认为，commit历史应该显示的是这个项目经历过的状态，而不考虑具体的分支构建过程。

每一个团队，每一个人都是不同的。git作为一个如此强大的工具提供给了你解决任何问题的思路，你就要考虑清楚你的团队到底需要什么。

一个两全其美的方法就是：rebase你本地的修改，push到多人环境中时用merge。

乱糟糟的时间线&&完整的分支结构 vs 清爽的一条线&&舍弃修改过程，看你团队取舍咯。