Git 分⽀管理策略

1. Fast forward 模式

通常合并分⽀时，如果可能，Git 会采⽤ Fast forward 模式。还记得如果我们采⽤ Fast forward 模式之后，形成的合并结果是什么呢？回顾⼀下

在这种 Fast forward 模式下，删除分⽀后，查看分⽀历史时，会丢掉分⽀信息，看不出来最新提交到底是 merge 进来的还是正常提交的。如下：

但在合并冲突部分，我们也看到通过解决冲突问题，会再进⾏⼀次新的提交，得到的最终状态为：

那么这就不是 Fast forward 模式了，这样的好处是，从分⽀历史上就可以看出分⽀信息。 Git ⽀持我们强制禁⽤ Fast forward 模式，那么就会在 merge 时⽣成⼀个新的 commit ，这样， 从分⽀历史上就可以看出分⽀信息。 下⾯我们实战⼀下 --no-ff ⽅式的 git merge 。⾸先，创建新分⽀ dev3 ，并切换⾄新的分⽀，修改 ReadMe ⽂件，并提交⼀个新的 commit：

切回 master 分⽀，开始合并

请注意 --no-ff 参数，表⽰禁⽤ Fast forward 模式。禁⽤ Fast forward 模式后合并会创建⼀个新的 commit ，所以加上 -m 参数，把描述写进去。合并后，查看分⽀历史：

可以看到，不使⽤ Fast forward 模式，merge后就像这样：

所以在合并分⽀时，加上 --no-ff 参数就可以⽤普通模式合并，合并后的历史有分⽀，能看出来曾 经做过合并，⽽ Fast forward 合并就看不出来曾经做过合并。

2. 分⽀策略

在实际开发中，我们应该按照⼏个基本原则进⾏分⽀管理：

⾸先，master分⽀应该是⾮常稳定的，也就是仅⽤来发布新版本，平时不能在上⾯⼲活。 那在哪⼲活呢？⼲活都在dev分⽀上，也就是说，dev分⽀是不稳定的，到某个时候，⽐如1.0版本发布时，再把dev分⽀合并到master上，在master分⽀发布1.0版本；你和你的⼩伙伴们每个⼈都在dev分⽀上⼲活，每个⼈都有⾃⼰的分⽀，时不时地往dev分⽀上合并就可以了。所以，团队合作的分⽀看起来就像这样：

3. bug 分⽀

假如我们现在正在 dev3  分⽀上进⾏开发，开发到⼀半，突然发现 master 分⽀上⾯有 bug，需要

解决。在Git中，每个 bug 都可以通过⼀个新的临时分⽀来修复，修复后，合并分⽀，然后将临时分⽀删除。可现在 dev3  的代码在⼯作区中开发了⼀半，还⽆法提交，怎么办？例如：

Git 提供了 git stash 命令，可以将当前的⼯作区信息进⾏储藏，被储藏的内容可以在将来某个时间恢复出来。

⽤ git status 查看⼯作区是⼲净的（除⾮有没有被 Git 管理的⽂件），因此可以放⼼地创建分⽀来修复bug。储藏 dev2 ⼯作区之后，由于我们要基于master分⽀修复 bug，所以需要切回 master 分⽀，再新建临时分⽀来修复 bug，⽰例如下：

修复完成后，切换到 master 分⽀，并完成合并，最后删除 fix_bug 分⽀：

⾄此，bug 的修复⼯作已经做完了，我们还要继续回到 dev3  分⽀进⾏开发。切换回 dev3 分⽀，git status 查看⼯作区是⼲净的，刚才的⼯作现场存到哪去了？⽤ git stash list 命令看看：

⼯作现场还在，Git 把 stash 内容存在某个地⽅了，但是需要恢复⼀下，如何恢复现场呢？我们可以使⽤ git stash pop 命令，恢复的同时会把 stash 也删了，使用 git stash list 再次查看的时候，我们已经发现已经没有现场可以恢复了, ⽰例如下：

但我们注意到了，修复 bug 的内容，并没有在 dev3  上显⽰。此时的状态图为：

Master 分⽀⽬前最新的提交，是要领先于新建 dev3  时基于的 master 分⽀的提交的，所以我们在 dev3  中当然看不⻅修复 bug 的相关代码. 我们的最终⽬的是要让 master 合并 dev3  分⽀的，那么正常情况下我们切回 master 分⽀直接合并即可，但这样其实是有⼀定⻛险的。是因为在合并分⽀时可能会有冲突，⽽代码冲突需要我们⼿动解决（在 master 上解决）。我们⽆法保证对于冲突问题可以正确地⼀次性解决掉，因为在实际的项⽬中，代码冲突不只⼀两⾏那么简单，有可能⼏⼗上百⾏，甚⾄更多，解决的过程中难免⼿误出错，导致错误的代码被合并到 master 上。

此时的状态为：

 

解决这个问题的⼀个好的建议就是：最好在⾃⼰的分⽀上合并下 master ，再让 master 去合并 dev ，这样做的⽬的是有冲突可以在本地分⽀解决并进⾏测试，⽽不影响 master 。此时的状态为：

对应的实操演⽰如下.

4. 删除临时分⽀

软件开发中，总有⽆穷⽆尽的新的功能要不断添加进来。添加⼀个新功能时，你肯定不希望因为⼀些实验性质的代码，把主分⽀搞乱了，所以，每添加⼀个新功能，最好新建⼀个分⽀，我们可以将其称之为 feature 分⽀，在上⾯开发，完成后，合并，最后，删除该 feature 分⽀。可是，如果我们今天正在某个 feature 分⽀上开发了⼀半，被产品经理突然叫停，说是要停⽌新功能的开发。虽然⽩⼲了，但是这个 feature 分⽀还是必须就地销毁，留着⽆⽤了。演⽰如下：

接下来要停⽌新功能的开发，即销毁feature 分⽀，这时使⽤传统的 git branch -d 命令删除分⽀的⽅法是不⾏的，而要使用 git branch -D 。