《CVS 精髓》

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

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