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

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

那么我们就把注意力集中在项目维护阶段。项目维护阶段最为常见的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)	开发人员主要进行开发的专用分支,其他人员无需使用该分支	当前正在开发的版本-Alpha
发布(Release)	主干(Main)	除紧急修复外,开发人员不能进行任何修改;发布人员专用的分支	当前已经发布的版本-Final

 
在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)	紧急修复代码签入发布分支,并发布