Google软件工程工具之版本控制与分支管理

没有哪一种软件工程工具，像版本控制工具一样在整个行业中被广泛采用。版本控制的使用在软件工程中已经成为一个明确的规范，某些版本控制策略和过程可能比其他策略和过程更适合你的组织。基于主干的开发是一种有利于规模化的方法。

版本控制把时间作为操作的一个明确部分，这对编程是不必要的，但对软件工程是非常必要的。回滚到以前的某个版本以消除错误是一种高级技巧。

版本控制还是一个分支与合并的过程，是在多个开发人员和多个时间点之间协调的工具。版本控制对代码的每一次变更进行记录，可满足法律和监管要求。

集中式版本控制系统是一个单一的中央存储库。分布式版本控制系统没有一个中心存储库。

分支等同于制品。组织中正在进行的每一项工作都等同于分支。

开发分支是已经完成但没有提交和这是新的工作基线之间的中间态。他们试图解决的问题是产品不稳定的问题。但是通过更广泛地使用测试、持续集成和强制的质量实践，如全面的代码评审，可以更好地解决这个问题。

将开发分支视为产品质量稳定的手段在本质上是错误的。基于合并长期存在的开发分支降低了稳定性的错误观察，得出合并分支是有风险的错误结论。

合并和重新测试是纯粹的开销。替代方案是一种不同的范式: 基于主干的开发，严重依赖测试和持续集成，保持构建为绿色，并在运行时禁用未完成和未测试的特性。每个人都自行负责提交到主干，并与主干同步，不需要合并策略会议，也没有大型昂贵的合并。

如果产品发布的时间间隔超过几个小时，可以创建一个发布分支，让这个分支只包含为了产品发布而创建的代码。

在最高效的技术组织中，发布分支是不存在的。基于主干的开发、没有长周期的开发分支、良好的技术成果之间存在很强的正相关关系。分支是生产力的累赘。

单一版本规则: 组织中的开发人员不能自行选择在哪里提交，或者依赖于现有组件的哪个版本。消除在何处提交或依赖什么的选择可以显著提升效率。