Git 扩展之分支管理原理

为什么需要分支

问题情景：开发人员在开发一个新功能，需要两天完成，第一天完成 50%，如果当天提交，由于代码还没写完，不完整的代码库会导致别人不能干活了。如果等代码全部写完再一次提交，又存在丢失第一天进度的巨大风险。

解决方案：创建了一个属于你自己的分支，别人看不到，别人可以继续在原来的分支上正常工作，而你在自己的分支上干活，想提交就提交，直到开发完毕后，再一次性合并到原来的分支上。

Git 分支的生命周期

我们知道，每次提交，Git都把它们（提交）串成一条时间线，这条时间线就是一个分支。最开始只有一条时间线，在Git里，这个分支叫主分支，即master分支。HEAD严格来说不是指向提交，而是指向master，master才是指向提交的，所以，HEAD指向的就是当前分支。

初始化后

一开始的时候，master分支是一条线，Git用master指向最新的提交，再用HEAD指向master，从而Git通过HEAD就能确定当前分支，以及当前分支的提交点。每次提交，master分支都会向前移动一步，这样，随着你不断提交，master分支的线也越来越长。

创建并切换到新分支

当我们创建新的分支，例如dev时，Git新建了一个指针叫dev，指向master相同的提交，再把HEAD指向dev，就表示当前分支在dev上（切换分支）。在Git中创建一个分支很快，因为除了增加一个dev指针（创建新分支），改改HEAD的指向（切换到新分支），工作区的文件都没有任何变化！

新分支上提交

不过，从现在开始，对工作区的修改和提交就是针对dev分支了，比如新提交一次后， dev指针往前移动一步，而master指针不变。

合并分支

假如我们在dev上的工作完成了，就可以把dev合并到master上。Git 怎么合并呢？最简单的方法，就是直接把master指向dev的当前提交，就完成了合并。所以Git合并分支也很快！就改改指针，工作区内容也不变！

删除分支

合并完分支后，可以删除dev分支。删除dev分支就是把dev指针给删掉，删掉后，我们就剩下了一条master分支：

Git 分支的合并

情景1

在master分支上，创建并切换到新的分支dev，在dev分支做了修改并提交后，又切换回到master分支，如何在master分支上合并dev分支？

解决方案：直接使用git merge dev命令将dev分支合并到master分支（当前分支）上，此时采用的是一种Fast-forward（快进模式）的合并方式，也就是直接将master指向 dev的当前提交。

情景2

Git用Fast forward模式合并分支后，如果删除分支，会丢掉分支信息，如何保留分支信息？

解决方案：强制禁用Fast forward模式（参数--no-ff），此时Git就会在合并时生成一个新的提交，这样，从分支历史上就可以看出分支信息。强制禁用Fast forward模式的命令git merge --no-ff -m "merge with no-ff" dev。

情景3

在master分支创建并切换到新的分支dev，在dev分支做了修改并提交，然后切换回到master分支，在master分支上也做了修改并提交（且修改的内容与在 dev分支修改的内容发生冲突），如何合并分支？

解决方案：如果直接使用git merge dev命令，Git将报告文件存在冲突，此时必须手动解决冲突后再提交。

情景4

当前正在 dev分支上工作，但工作还未完成，无法提交，但同时需要修复另外一个新的 bug，怎么办？

解决方案：将当前dev分支（有修改当没有提交）的工作现场储藏起来，等以后恢复现场后再继续工作

分支策略

• master分支：master分支应该是非常稳定的，也就是仅用来发布新版本，平时不能在上面干活
• dev分支：干活都在dev分支上，比如1.0版本发布时，再把dev分支合并到master上，在master分支发布1.0版本
• bug分支：bug分支常用于修复某一个 Bug，
• feature分支：feature分支常用于开发某一个新功能
  

参考：廖雪峰的 Git 教程