常见的几种分支开发方式

一、背景

1、版本控制最经常用在软件开发领域

分支管理的策略确实很考验对人性的理解，从理念上说它要

- 符合人性
- 能自动化的就不要人工做，缺少工具支持的流程就是耍流氓 

要让它既灵活，又简单，就需要

1. 首先别让我记住很多规则
2. 其次别让我做很多合并
3. 最后是敏捷，如何让我不要被别人耽搁 

所以：

1. trunk 发布是最简单的规则，任何时候不管是家里，公司，新人旧人都可以记住
2. 迭代分支直接开发，免去特性分支到迭代分支的合并，简洁易行
3. 提前做好迭代的规划，迭代分支已经是比较不可分割的整体，全体特性一起上或一起延迟，敏捷是有限度的

2、问题

并行软件开发是企业级环境下软件开发的一种不可避免的模式，这种开发模式可以说是任何大中型软件产品和项目所必需的。然而，并行开发在为我们的开发效率提高保证的同时，也会给我们的开发管理带来诸多问题：

• 什么时候进行分支？
• 什么时候进行合并？
• 如何选择有效的分支策略？
• 如何保证不同分支上的代码同步问题？
• 如果建立对分支访问控制的授权机制？
• 如何避免频繁的合并冲突？
• 如何处理被复用的代码？

二、说明

1、主干开发

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

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

缺点：

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

 

主干开发在这里的含义如上图，它有如下特征：

1. 所有人工作在单一的主干上
2. Bug fix也在主干进行
3. 没有代码会被冻结
4. 没有merge灾难
5. 不会build broken，它永远是release-ready状态 

对于极小型的、业务功能不大变化的Service/API项目，或者是线上bug紧急fix，我们依然使用主干开发。它是最简单、最可控的一种。

2、按发布创建分支

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

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

3、按功能特性创建分支

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

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

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

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

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

4、按团队创建分支

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

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

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

三、注意事项

最后，说说分支合并管理的一些注意点：
1.分支离开主干的时间要尽可能短。长期离开主干的分支需要定期合并。
2.辅助文档是必需的。为了观察分支的创建和合并的过程，至少需要一份类似泳道图的文档标记每一次分支创建和合并的过程。
3.开发分支往主干或者发布分支合并的次数应该尽可能少。一般来讲应该在单体测试结束合并到主干或者发布分支，然后进行结合测试。如果结合测试里发现bug不应该在原来的开发分支上继续修改，而应该创建新的分支进行修改。
4.分支创建和合并的log必须规范。便于以后查找。基本的log信息应该包括从哪个个分支的哪个版本创建分支；把哪个分支的从哪版本到哪个版本范围内的变更合并到了哪个分支的哪个版本，合并后的版本号。这些信息有一些是版本控制工具本身可以很方便查找到的，就可以省略。

四、参考路径：

1、https://www.tapd.cn/forum/view/69961

2、https://svnbook.red-bean.com/zh/1.8/svn.branchmerge.commonpatterns.html

3、https://www.cnblogs.com/shihao/archive/2012/03/28/2421224.html

4、https://www.jianshu.com/p/87e75a69ed17

5、https://blog.csdn.net/iteye_4392/article/details/81597716