在大型专案使用版本管理工具

应该是所有软件开发，必须必须版本管理

作者：周思博(Joel Spolsky)
属于Joel on Software， http://www.joelonsoftware.com

在大型专案使用版本管理工具

在微软公司搞砸的所有事里，视窗开发团队使用版本管理的方式是得以幸免的项目之一。

一位年轻的视窗开发工程师写道：

「……在重启Longhorn的专案之前，他们大约有七个分支（译注：分支，是版本管理工具常会提供的功能之一，可以将目前管理的专案发展出多个支线，每个支线可各自发展，却又保持有所关连），然后大约每二或三周，将这些分支整合回主要分支上现在，想像有数千个开发者将他们的程式码直接提交（译注：检查 在，将开发者修改的部分程式码上传到版本管理伺服器）到这七个分支上，会导致以下两个状况：

「1.你频繁的提交程式码，这很容易导致现有版本无法编译，或者作业系统功能有问题; 2。相反地，假若你没有常常提交程式码（这明显是很糟糕的事），会让你无法良好地回溯追踪修改历史。

「这明显地不具有弹性。因此重启专案之后，我们决定每个团队应该要有他们自己的功能分支，每个「功能分区」（跨多个团队）会再汇整成一个支线，最后整合成最终的主要支干。（因此目前有上百个分支，分属于大约六个支线之下）各团队可自由地选择他们需要的分支，并且可自由地决定上传修改部分到支线的频率。回归整合（译注：反向 积分， RI，意思是将修改的内容汇整回主要支干）需要通过多种品质鉴定，像是效能测试。视评量关卡的多寡而定，至少会花掉一天的时间来进行这整个流程，再加上一两天的时间应付突发状况，所以进行一次RI需要相当的成本。然而，这些评量关卡都是为了确保主要支干上的产品的品质，如果没有这些关卡，这套作业系统大概永远无法推出我认为这是那种「不会害死你」的交易（译：代价有点高但还是值得做）。

「有些团队的确以用不健康的方式来进行专案，像是数个月才RI一次，但这是这些个别团队的问题（或者说是他们的发布管理），而不是流程的错。一般来说，在品质方面越有纪律的团队，其RI的频率会更快更频繁。从你获得的系统元件稳定度/品质等级的变化资讯，可以轻易的推测出RI的速度等等，这是因为这些事情都是紧密的相连在一起。

在大型团队中使用版本管理机制时，最佳的方法是依各高阶功能分组，对个别的功能团队创造出分支跟子分支。假若工具能支援，甚至可以让每位开发人员有一个私有分支，这样一来，他们就可以随时提交到私有分支，直到自认程式码稳定了才整合至团队分支.QA部门负责每次整合的合并点（结 点）。亦即当开发人员将私有分支的内容整合回团队的分支后，QA就态尽快查验，只有符合品质标准之后才能继续往上整合。

还是一头雾水吗？看一下AccuRev的这套软体的[使用画面（http://www.accurev.com/images/screenshots3_7/BigStream.png）吧，上头有许多的「叶」分支，必须通过QA检验后功才能整合到更接近主线的分支。顺便一提，[AccuRev的]（http://www.accurev.com/）针对这种密集分支与整合的开发模式，做了一套很不错的版本管理系统.Windows开发团队使用他们自己的版本管理系统，不过谣传这其实是被买下原始码版权的旧版[Perforce的]（http://www.perforce.com/）系统.Perforce在开发者间以昂贵稳固闻名，而且在处理超大型的程式码库时效率很高。