分支管理是代码管理中比较重要的组成部分，在新项目开发中，由于不存在维护系统稳定和紧急修复错误的压力，所以单分支模式基本是可以胜任的；而在项目维护过程中，开发组需要在维护系统稳定的前提下不断改进系统，同时也承担了立刻修复紧急错误的时间压力，这个时候，单分支已经远远不能满足开发的要求，必须寻求多分支的解决方案。

那么我们就把注意力集中在项目维护阶段。项目维护阶段最为常见的2种开发流程是：

· 需要立刻修复的紧急错误更新流程（HotFix）。

· 以版本方式进行管理的周期式开发流程。

而在维护系统稳定性这一个大前提下，开发组不得不面临3个开发中的矛盾：

A. 紧急修复的即时性和版本开发的周期性的矛盾。

B. 版本连续开发中，开发和测试存在时间差。

C. 遇到特殊情况没有回旋余地，如版本中的任务临时取消和加入，或者紧急修复被取消等情况。

下面利用一些场景来详细说明一下在单分支开发模式下这3个矛盾到底带来了什么样的问题：

A场景：当前版本1.0，而1.1版本正在开发过程中，涉及到代码a, 改动比较大，而且部分代码已经签入（Check In），此时出现紧急错误，错误代码正好也是a，由于1.1版本没有完成开发，所以修复错误时不能把a的最新改动包括在内，而a的已有改动比较大，合并（Merge）代码难度很大，单分支开发陷入困境。

B 场景：当前版本1.0， 1.1 版本开发完成，开发组提交1.1版本给测试组测试，此时测试组尚未发现任何问题，开发组继续开发1.2版本（同一分支），并签入了部分代码（该部分代码属于1.2版本）。此时，测试组测出1.1版本问题，返回开发组修复，开发组修复后再次签入代码（该部分代码仍旧属于1.1版本），此时1.1版本代码和1.2版本代码交叉，不但给1.1 版本的发布带来困难,而且在某些情况下，1.2的修改正好和1.1版本的修改重叠，带来极为困难的合并问题。

C场景：当紧急错误的修复被临时取消,或者1.1完成后其中的某一个任务被临时取消,或者1.2版本的一个改动需要临时加入1.1版本,一旦这些情况出现在单分支开发模式中,将引起非常致命的代码交叉问题.

注： 利用基于修改集（ChangeSet）的合并技术，可以局部缓解上述矛盾(但仍然需要2个分支)，但正所谓躲得过初一躲不过十五，在很多情况下，即使是基于修改集的合并，也无法解决所有问题，而如果版本或错误的更新无法正常进行，会给项目维护带来无法估计的风险。

综上,在一般的项目维护中,我们必须采用多分支开发方案,最为基本的分支开发方案是由主干(Main)-开发(Development)-发布(Release)组成的3分支方案,见下图:

首先,如果要在你的开发中运用这种分支方案,必须满足以下3个条件:

1. 你的系统只有一个版本发布给最终用户.

2. 你的维护方式是让客户不断升级到下一个版本.

3. 所有对系统的修改都必须包含在下一个版本中.

很多系统的维护都能满足这3个要求,所以说3分支方案是最为实用的分支解决方案.

3分支方案的简单开发实施方法见下表:

在3分支开发过程中,各个分支的代码流动并不是随意的,下面我会借助示意图对不同场景下的代码流动做出详细的说明:

注1:下图中的FI(Forward Integrated)是指将主干分支的代码合并到开发分支, RI(Reversed Integrated)是指将开发分支的代码合并到主干分支.

注2:场景的假设是,当前系统版本是1.0,并正常运作的情况下.

关于本模式的实战和特殊情况处理 请参阅 敏捷开发中最基本的分支管理模式实战和补遗