版本管理 分支创建的策略

laofo · 2012年04月02日 · 8 次阅读

《CVS 精髓》

创建分支的基本原则是:将开发主线放在干线上,其余则纳入分支。问题在于何者为开发主线。干线应该包含稳定的程序代码还是不稳定的程序代码?每一个发布版本在测试的时候是否应该创建分支?新功能应该在干线上开发还是应该在分支上开发?

这些决策源自对开发主线的两种不同定义。这两种定义对分支的创建产生了两种定义。这两种定义对分支的创建产生了两种不同的哲学观,分别称为以稳定为集成和以不稳定为基础。 以稳定为集成 以稳定为基础的分支创建哲学是:干线所放的项目数据应该是最接近准备发布的程序代码;分支用来开发、修复缺陷和发布前的质量保证以及重构。分支也可以用来开发实验性质的程序代码。 以稳定为基础的最严格的做法是:没有经过 QA 验证的内容都不能被合并到干线上。这样可以确保无论何时都可以从干线取得准备发布的版本,只要再经过一些 QA,就能发布或出售。 比较宽容的做法是:通过开发人员单元测试(unit test)的任何内容都可以被合并到干线。这种宽松的做法必须把准备发布的版本放到分支中,并于发布前进行全面的 QA 分析。 以稳定为基础的优点如下: 任何时候都能从干线取得发布版,经过 QA 检验就能发布; 因为干线含有不会经常改变的稳定程序代码,所有你可以在分支中进行试样性质的工作,这样即使合并到干线,也不太可能造成别人的工作出错。 以稳定为基础的最大缺点是合并工作通常由 QA 测试来做,而非懂得所有合并的程序的真正意义的人来做。此外,分支建立以后以及合并前这段期间,干线可能有大幅的变更。 以不稳定为基础的分支创建哲学是: 干线应该包含最新的程序代码 - 无论是否稳定,而准备发布的版本则应该被创建为分支来进行 QA。 以不稳定为基础的最严格的做法是:所有的开发都在干线上进行,而分支只用于准备发布的版本、缺陷修复分支以及发布版。 比较宽松的做法是:也让分支用于试验性质的程序代码、重整以及其他特殊情况的程序的代码。由分支的管理者负责把分支合并回主线。 以不稳定为基础的优点是不合并不会经常做,而且比较好做,因为通常是由熟悉程序代码的人来做。 以不稳定为基础的缺点是干线中程序代码经常会包含缺陷、试验性质的工作,而其有时根本无法编译,尤其是采用最严格的做法时候。常贴标记可以减少这类缺点,因此每次有做好的程序代码时,或者有人开始进行试样或重构时,就要贴标签。较宽松的做法会让程序代码包含最多的缺陷,而且这些程序代码最有可能造成干线的严重毁坏,使得准备发行发布版的准备时间不足。 分支类型

学习了,谢谢 LZ 分享。 一直只知道大概的概念,今后要试试在具体项目中用用。。。。

目前我们实施的是后一种,即以不稳定为基础的分支创建。主干上是不稳定的代码,但每天都会定时构建一次主干,要保证能够编译通过。而分支代码相对稳定,每天提交的修复都会通过 code review, 单元测试才会进入分支。

需要 登录 后方可回复。