常见的几种分支开发方式

读书笔记 – 版本控制进阶

1、主干开发

在这种模式下，开发人员几乎总是签入代码到主干，而使用分支的情况极少。主干开发有如下三个好处：

• 确保所有的代码被持续集成
• 确保开发人员及时获得他人的修改
• 避免项目后期的“合并地狱”和“集成地狱”

缺点：

每次向主干签入并不都是可发布状态

2、按发布创建分支

在这种模式下，在某个版本即将发布之前，创建一个分支，该发布版本的测试和验证全部在该分支上进行，而最新的开发工作仍旧在主干上进行。要遵循如下规则：

• 一直在主干上开发新功能
• 当待发布版本的所有功能都完成了，且希望继续开发新功能时才创建一个分支
• 在分支上只允许提交那些修复严重缺陷的代码，并且这些修改必须立即合并回主干
• 当执行实际的发布时，这个分支可以选择性的打一个标签

3、按功能特性创建分支

这种模式是为了让开发团队更容易在“特性”层次上并行工作，并保持主干的可发布状态。

每个用户故事或者特性在不同的分支上开发完成，一个故事只有通过测试人员验证无问题后，才会被合并到主干上，以确保主干一直是可发布的。

该模式的动因是希望一直保持主干的可发布状态。

要想让这种模式有效果，有一些前提条件：

• 每天都要把主干上的所有变更合并到每个分支上
• 每个特性分支都应该是短生命周期的，理想情况下应该只有几天，绝不能超过一个迭代周期
• 活跃分支的数量在任意时刻都应该少于或者等于正在开发当中的用户故事的数量。除非已经开发的用户故事合并回主干，否则谁都不能创建新分支
• 在合并回主干之前，该用户故事应该通过测试人员验收通过。只有验收通过的用户故事才能合并回主干
• 重构必须即时合并，从而将合并冲突最小化，这个约束非常重要，但也可能非常痛苦，进而限制了这种模式的使用。
• 技术负责人的一部份职责就是保证主干的可发布状态

4、按团队创建分支

这种模式试图解决如下状况：在一个大型团队里，有很多开发人员同时工作在多个工作单元上，并且还要维持主干总是处于可发布状态。

下面是按团队分支的工作流程：

1. 创建多个小团队，每个团队自己都有对应的分支
2. 一旦某个特性或用户故事完成了，就让该分支稳定下来，并合并回主干
3. 每天都将主干上的变更合并到每个分支上
4. 对于每个分支，每次签入后都要运行单元和验收测试
5. 每次一个分支合并回主干时，在主干上都要运行所有的测试（包括集成测试）