第18章　Git分支

分支是我们的老朋友了，第6章、第7章和第8章就已经从实现原理上介绍了分支。您想必已经知道了分支master的存在方式无非就是在目录.git/refs/heads下的文件（或称引用）而已。也看到了分支master的指向如何随着提交而变化，如何通过git reset命令而重置，以及如何使用git checkout命令而检出。

之前的章节都只用到了一个分支：master分支，而在本章会接触到多个分支。会从应用的角度上介绍分支的几种不同类型：发布分支、特性分支和卖主分支。在本章可以学习到如何对多分支进行操作，如何创建分支，如何切换到其他分支，以及分支之间的合并、变基等。

18.1　代码管理之殇

分支是代码管理的利器。如果没有有效的分支管理，代码管理就适应不了复杂的开发过程和项目的需要。在实际的项目实践中，单一分支的单线开发模式远远不够，因为：

成功的软件项目大多要经过多个开发周期，发布多个软件版本。每个已经发布的版本都可能发现Bug，这就需要对历史版本进行更改。

有前瞻性的项目管理，新版本的开发往往是和当前版本同步进行的。如果两个版本的开发都混杂在master分支中，肯定会是一场灾难。

如果产品要针对不同的客户定制，肯定是希望客户越多越好。如果所有的客户定制都混杂在一个分支中，必定会带来混乱。如果使用多个分支管理不同的定制，但若是管理不善，分支之间定制功能的迁移就会成为头痛的问题。

即便是所有成员都在为同一个项目的同一个版本进行工作，每个人领受任务却不尽相同，有的任务开发周期会很长，有的任务需要对软件架构进行较大的修改，如果所有人都工作在同一分支中，就会因为过多过频的冲突导致效率低下。

敏捷开发（不管是极限编程XP还是Scrum或其他）是最有效的项目管理模式，其最有效的一个实践就是快速迭代、每晚编译。如果不能将项目的各个功能模块的开发通过分支进行隔离，在软件集成上就会遭遇困难。

18.1.1　发布分支

在2006年我接触到一个项目团队，使用Subversion做版本控制。最为困扰项目经理的是刚刚修正产品的一个Bug，马上又会接二连三地发现新的Bug。在访谈开发人员，询问开发人员是如何修正Bug的时候，开发人员的回答让我大吃一惊：“当发现产品出现Bug的时