持续交付发布可靠软件的系统方法（交付生态圈）第十四章：版本控制进
版本控制用来维护应用程序每次修改的完整历史，包括源代码、文档、数据库定义、构建脚本和测试等。团队可以在一个代码版本控制库上一起开发应用程序的不同部分。一旦团队人数超过一定数量，就需要规划版本控制库的使用，让开发更加高效。
分支与合并
分支，即为选择的基线创建一个副本，该副本与原基线相互独立，开发者能在两个工作流上同时开发。
团队为什么使用分支？
- 物理上：系统物理配置而分支，即为文件、组件和子系统而分支
- 功能上【最常见】：系统功能配置而分支，即为特性、逻辑修改、缺陷修复和功能增加，以及其他可交付的功能而分支
- 环境上：系统运行环境而分支，即由构建平台和运行时平台的不同而分支
- 组织上：团队的工作量而分支，即为活动/任务、子项目、角色和群组而分支
- 流程上：团队的工作行为而分支，支持不同规章政策、流程和状态而分支
在开发中，经常会遇到分支合并的情况，除非那些为了发布或者技术预研而创建的分支。两次合并时间间隔越长，每个分支上工作的人越多，合并发生冲突的可能性就越大。以下两种方法来减小冲突：
- 创建更多的分支来减少在每个分支上的修改。这只是将痛苦延后而已。
- 很谨慎地创建分支，可能每个发布才创建一个分支。为了尽量减少合并的痛苦就经常做合并。
一个强烈推荐的分支策略是：只为发布创建长期的分支。这种模式下，新开发的代码总是被提交到主干上，只有在发布分支上修改缺陷时才需要合并，而这具合并是从分支合并回主干。只有非常严重的缺陷修复才会从主干合并到发布分支上。
分布式版本控制系统（Git）
分布式版本控制系统就是每个使用者本地都有一个完整的代码仓库。它有了很多新特性：
- 在几秒内就能开始使用分布式版本控制系统
- 可以单独从别人那里拿到他们的最新更新，不需要提交到中央代码库
- 可以将自己修改推送到一组人的代码库中，而不需要他们每个人来取你的修改
- 补丁可以通过网络用户更高效地传播
- 没有网络的时候，也可以对修改的代码版本控制
- 可以频繁地提交未完成的功能到本地代码库，而不影响其他人
- 将修改发送给其他人之前，可以很容易地在本地对这些提交进行修改，重排它们的顺序或者将多次提交打包成一个，这个叫‘rebasing'
- 很容易用本地代码库来尝试各种解决方案或想法
- 能在本地把多次提交打包
- 在本地建立和同步多个代理库很容易，有更高的可用性
- 全量代码有很多份副本，有更好的容错性
主干开发
开发人员总是提交代码到主干，而使用很少使用分支。这有以下三个好处：
- 确保所有代码被持续集成
- 确保开发人员及时获得他人的修改
- 避免项目后期的“合并地狱”和“集成地狱”
开发人员在主干上工作，每天至少提交一次代码。当需要做复杂的修改时，修改会被分成一系列小的增量步骤有计划地实现，而每个步骤都会通过测试且不会破坏已有的功能。
主干开发并不排斥分支，只有当不需要合并回主干时，才创建分支。如发布分支，技术预研分支。
如果开发人员很多，且有多个版本发布的大型团队，软件需要良好的组件化、增量式开发和特性隐藏。要做的是持续频繁地向主干分支提交代码，每天至少一次提交。
按发布创建分支
在某个版本即将发布之前，创建发布分支。该分支一旦创建，该发布版本的测试和验证全部在该分支上进行，而最新的开发工作仍然在旧的主干分支上进行。发布分支上只做严重缺陷的修复。遵循如下规则：
- 一直在主干上开发新功能
- 当待分布版本的所有功能完成，且希望继续开发新功能时才创建一个分支
- 在分支上只允许提交修复严重缺陷的代码，且这些修改必须立即合并到主干
- 执行实际的发布时，这个分支可以选择性地打个标签
不要在已有的发布分支上再创建更多的分支，所有后续分支都应该从主干上创建。
一旦发布频率达到一定的频率（比如一周一次），就没必要创建分支了，在这种情况下，发布一个新版本要比在已发布的分支上打补丁更容易，成本更低。而且部署流水线机制可能为你保留了一份记录，包括发布的软件在版本控制库中对应的修订版本号。
按功能特性分支
为了让开发团队更容易在“特性”层次上并行工作，并保持主干为可发布状态，这时使用特性分支。
使用特性分支，需要遵循以下规则：
- 每天都要把主干上的所有变更合并到每个分支上
- 每个特性分支都应该是短生命周期的，理想情况只有几天
- 活跃分支的数量随时都应该少于或等于开在开发当中的用户故事的数量。只有在已经把开发的用户故事合并回主干，才允许创建新的特性分支
- 在合并回主干之前，该用户故事应该已经由测试人员验收通过
- 重构必须即时合并，从而将合并冲突最小化
- 技术负责人的一部分职责就是保证主干的可发布状态
按团队分支
团队分支模式的工作流：
多个开发人员同时工作在多个工作流上，还要保证主干随时可发布状态
- 创建多个小团队，每个团队自己有对应的分支
- 一旦某个特性或用户故事完成，让该分支稳定下来，合并到主干
- 每天都将主干上的变更合并到每个分支上
- 对于每个分支，每次提交代码都要运行单元测试和验收测试
- 每次分支合并回主干时，主干上也要运行所有的测试，包括集成测试
在有几个比较小而且相对独立的团队，同时各团队负责该软件系统中功能相对独立的情况下，该模式才有效。
从持续集成的角度说，该策略有一些缺点，根本问题是该模式下的工作单元是一个分支，而不是一次特定的修改。
这种模式与特性分支模式很类似。它的优点是：分支较少，所以集成工作会频繁一些。缺点是：各分支很快会变得差异很多，在合并操作时会更复杂。团队分支很快会和主干变得很不一样，差异很大，合并冲突可能很快就变得极其痛苦。
推荐使用“功能隐藏”的方式进行增量开发，从而做到应用程序随时可发布。即使某个功能特性正在开发中，也把它隐藏起来，这种方法需要更多的纪律性，但风险小，避免了分支的不断合并带来的复杂性，而且可以快速得到某次提交对整个应用的影响的反馈，这正是真正的持续集成可以提供的。
