敏捷开发中最基本的分支管理模式解析

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

那么我们就把注意力集中在项目维护阶段。项目维护阶段最为常见的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分支方案的简单开发实施方法见下表:

分支名称	源分支	开发方式	对应版本
主干(Main)	无	测试人员进行测试的专用分支,除非是修复测试人员提出的错误,否则开发人员不能修改该分支	当前正在测试的版本-Beta
开发(Development)	主干(Main)	开发人员主要进行开发的专用分支,其他人员无需使用该分支	当前正在开发的版本-Dev
发布(Release)	主干(Main)	除紧急修复外,开发人员不能进行任何修改;发布人员专用的分支	当前已经发布的版本-Live

 

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

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

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

 

 

场景	主干分支	开发分支	发布分支
1.1版本开始开发	无变化	开发组签入1.1版本代码	无变化
1.1版本开发结束	开发分支代码合并入主干(RI)	无变化	无变化
1.1版本开始测试	开发组签入1.1错误修复代码	定期将主干代码合并到开发分支(FI)	无变化
1.1版本测试完毕	无变化	无变化	主干分支代码合并入发布分支准备发布
1.2 版本开始开发	无变化	开发组签入1.2版本代码	无变化
修复紧急Bug	发布分支的修复代码合并入主干分支	定期将主干代码合并到开发分支(FI)	紧急修复代码签入发布分支,并发布

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