敏捷的版本管理

软件开发中的配置管理非常重要的一环是如何管理版本。版本管理的技巧是决定你的项目是否能够敏捷的关键。其实，这个所谓技巧很简单，就是做最简单的事，只要不把事情搞复杂了，事情就好办了。

假设使用的是Subversion（其他的也类似），最简单的版本管理是这样的，

1. 所有人都用Trunk，Check-in的时刻可以是每天几次，也可以是每个Sprint Backlog完成后一次。
2. 每天晚上，把Trunk重建一次，产生一个到那天为止最正式的版本，放在/tags/daily/1.0.b，这里b是一个序号，从零开始，每次加一。如有必要，也可以随时重建。
3. 每个Sprint结束时，把最后一个tag复制到/tags/release/1.0.15，假设15是最后一个版本。

可见这里其实并没有建立分支，也可以达到目的了。这当然是假设每次的发布都是包含新Product Backlog的版本，如果需要给产品只打补丁，事情就开始稍微复杂一些。我们可以这样做：

1. 到/tags/release中找到在线上的产品的版本，例如是/tags/release/1.0.15，将其复制到/branch/1.1。
2. 类似上面的步骤，每天晚上，把/branch/1.1重建一次，放在/tags/daily/1.1.b。b也是从零开始，每次加一。
   
3. 打补丁结束时，把最后一个tag复制到/tags/release/1.1.3，假设3是最后一个版本。
   
4. 如果需要，可以在这个时候把所打的补丁移植到Trunk里面去。

随便一提，这里的版本号由三个数字组成，f.p.b，其中，f是Feature号，p是Patch号，b是Build号。如果发布的版本有新的Feature，f加一；如果是一个补丁，p加一；对于任意一个f.p的组合，b都是从零开始，每次重建，都要加一。

有一种习惯是要程序员把要Check-in的东西先Submit到一个临时的Branch，到一定的时候，才把这些东西Merge到上述应该Submit的地方。这种方法显然与敏捷的概念矛盾，而且Overhead很大，不值得在敏捷项目中推荐。