也谈使用分支
近期在为一个新项目作版本库规划，并策划一些即将应用于该项目的版本控制和发布流程的Rules。借此机会我也花上一些时间对我们之前的版本控制和发布流程进行一下反思，也翻看了一些书籍(比如《版本控制之道-使用subversion》、社区自由图书《Subversion与版本控制》等)，了解一下Best Practice是什么样子的，同时也纠正一下我之前理解不正确的地方。
我们这些年来一直在使用CVS/Subversion这些版本控制系统进行源码管理，但若干年来似乎没有什么改善，仍然在走最初的路子进行版本控制和发布，这也导致我们仍旧挣扎在繁乱的版本库中。未经精心策划过的版本库组织及发布管理流程还在一定程度上降低了团队的工作效率。
年初曾协调开发团队和测试团队共同制定了一些版本管理和发布流程的改善措施，目前收到了一定效果，但是我个人觉得与最佳状态相比，我们还是有差距的。差距主要还是体现在对VCS系统的几个概念拿捏的不够好，比如说分支。
现在的程序员已经足够幸福了，前人经过几十年的实践给我们留下了版本控制的一些最佳实践，你在介绍CVS、SVN或GIT等VCS工具的书籍中都能读得到。之前没有静下心来好好读一读这类的书籍真是有些遗憾，走了许多弯路。
版本控制工具应用的核心应该是对分支、标签的把握，这其实也是最难的，它可不仅仅是简单命令的使用，而是体现着对软件开发流程的整体把握能力。
如何使用分支等高级概念取决于你对软件生命周期的规划，如果一个软件产品极其简单，简单到发布一个版本后就不需要增加feature和Bugfix了，那你根本不需要用到分支，甚至标签都可省去。但实际生活中我们面对的是一个复杂的世界，多数软件产品都会有一个较长的生命周期，在这个生命周期里程序员们需要为它增添feature，为它Fix bug，这样分支等概念就能派上用场，可以帮助你更佳清晰的管理版本以及提升开发和测试的效率。
Subversion引入了“TTB(Trunk-Tags-Branches)”的实践，其核心也是分支的使用。资料中多将分支分成两种类型，一种称为”Release Branch(发行分支)”，另外一种是”Feature Branch(特性分支)”。我们还是结合一个例子来说明两者的差异吧。
一般一个项目在初始阶段都会有相应的负责人对产品的版本进行规划，比如对与testproj这个项目来说，规划如下：
version 1.0.0
– feature#1
– feature#2
– feature#3
version 2.0.0
– feature#4
– feature#5
version 3.0.0
– feature#6
– feature#7
规划版本号采用标准的[major.minor.revision]格式。版本库组织采用标准的TTB形式，即：
testproj(root)
– trunk
– branches
– tags
之后大家就一起在trunk上编码，测试，提交，乐此不疲^_^。直到有一天开发leader宣布feature#1~#3编码+UT的工作基本OK了。下面的工作将会出现岔路口，一组人要继续在trunk上开发feature#4~#5，另外一组人则要继续执著于feature#1~#3直到1.0.0版本最终发布。分支此时该出面解决问题了。不过如何创建分支、创建什么类型的分支，出现了两种意见:
1、创建”发布分支，Release Branch”
——- Rel_1.0.0(Tag)
|
—–rel_branch_1.0 —————————->
|
—————————————————————> trunk
如上图所示，在leader宣布feature#1~#3基本OK时创建了一个分支rel_branch_1.0，一组人将转移到这个分支上开发，另外一组将继续在thunk上开发后续features。QA对rel_branch_1.0进行严酷的测试，测试完毕后打Tag发布Rel_1.0.0正式版本。也就是说发布版是基于Branch的，且该branch会与trunk长时间并行开发一段时间（甚至可能很长），并得到足够支持。比如后续在trunk上或其他分支上发现的bug需要merge到该分支上，并在适当时刻发布补丁版本，比如Rel_1.0.1等。甚至可继续在此分支上继续增加新Feature，形成1.1.0等发布版本。
2、创建”特性分支，Feature Branch”
———Feature_branch_2.0 ——-
| |
—————————————————————> trunk
|
——- Rel_1.0.0(Tag)
特性分支与发布分支恰相反，如上图所示，一组人继续在trunk上fix bug，直到Rel_1.0.0版本发布;其他人建立一个Feature_branch_2.0的特性分支，在该分支上开发新Features，并定期从trunk上merge trunk上的bugfix。Feature_branch_2.0开发完毕后，将分支代码merge回trunk，之后QA对trunk的最新代码进行测试，直到完毕后发布Rel_2.0.0，此后Feature_branch_2.0这个特性分支已经不再需要，它的生命周期也到此为止，可删除之。
两种类型分支如何选择呢？其实实际软件开发中两种类型分支是你中有我，我中有你的。如果从宏观来看，其实更多还要看你的产品的特点和规划，如果类似GCC这样的产品，“发布分支”必不可少。比如我曾用过的GCC的版本有2.95.x、3.2.x、3.3.x、3.4.x等，GCC对于每组[major,minor]都要有一个“发布分支”，至少是用来fix bug的，在3.2上发现的bug要同步回2.95，发布2.95新补丁，除非GNU宣布对GCC 2.95不再支持。如果一个产品的bugfix不需要回溯到以前的版本，而是一直采用trunk上的最新版本，那特性分支则更适合，这样也避免了在N多发布分支上频繁merge代码的情况了。但是特性分支不宜建多，最初我也考虑是否每人建立一个关于自己任务的分支，后来发现这样会给后期merge代码带来诸多不便。
发布分支上如果要新增个性化feature，就好比发布分支变成了”trunk”，后期也可以采用feature分支的形式来开发，保持了”trunk”上代码的稳定、可用;当然如果不太在意这点，你大可直接在该”trunk”上直接开发。
目前我所在的产品线采用的就是发布分支和特性分支结合的方式，不过产品的电信行业背景决定了产品需求多变、客户间需求差异较大，增加了我们的版本发布管理复杂性。单独在该分支上采用“特性分支”的开发流程已经不能满足需要了，因为我们有时候需要回溯到某个早期发布版上fix bug或增加feature，到了在发布分支上再建立发布分支的时候了。但为了减少后期分支数多、在各个分支上同步代码工作量大且较难跟踪管理的情况，我们采取了一些措施。比如我们目前采取的策略是尽量减少版本的个数、减少发布的次数(达到减少发布分支个数的目的)，将两个版本之间交付间隔拉长（版本多为我们自己策划），将不同客户的需求转化为产品的通用功能进行统一管理，减少因版本功能差异带来的版本管理上复杂性。当然了也不能少了与客户沟通和协调，说服客户接受将其提出的个性化功能纳入到某个大版本中统一发布。
工具和概念都有了，一切还在于人的规划。简单和清晰是我们应该在版本规划、控制和管理中追求的目标，这样才易于理解、易于执行，减少不必要的工作，毕竟不是所有人都是这方面的专家。
评论