开发分支

Hi，我是阿昌，今天学习记录的是关于开发分支的内容。

组件化，软件变得更加高内聚、低耦合，开发及维护的效率也更高了，但是组件化的架构又会引入新的复杂度。

举个例子，在重构前我们基于一个模块一次编译就出一个版本，而组件化架构需要同时维护更多的组件版本以及管理更多组件的集成，这就又增加了复杂度。

一、分支作用

在版本控制与软件配置管理中，分支 是从某个版本的代码或文件中建立复制版本，在分支后的两个版本里都可以独立做修改。

分支有什么作用呢？

举几个研发过程中使用分支的常见场景。

• 有几个功能需要同时在研发，为了互相不干扰，拉取各自的 Feature 分支进行开发。
• 有多个线上发布版本需要同时维护，为了便于追溯，每个版本都会维护各自的 Release 分支。
• 线上版本出现 Bug，为了快速修复，基于发布分支拉取 HotFix 分支进行修复。
• … …

结合这些场景，不难分析出，拉分支的主要目的是并行开发不同的功能，同时不让开发中的功能受到其他并行功能的影响。

分支让可以更加灵活地控制软件版本的发布，以及团队并行开发之间的协作。但是，很多团队往往会因为缺少分支的规范及有效的管理，出现大量的长期并行分支，这样就会影响开发效率。

—.

分支 管理不当，就会导致后面这些问题。

• 由于存在大量的并行发布分支，当修复一个问题的时候，需要花费大量的时间在各个分支上进行代码同步。
• bug 修复了，但是没有及时同步到主干分支，导致提测的时候又出现相同的问题。
• 拉了特性分支开发，由于时间比较久，代码差异越来越大，最后代码合并不回去。
• ……

分支给带来灵活性的同时，如果不能有效规范其的使用，最后反而会降低团队的研发效率。

二、分支模型

那么如何来解决 分支管理混乱 的问题呢？

一个有效的方式就是在团队内部采用统一的分支模型，规范分支的拉取及合并。

3 种常用的分支模型，它们分别是：

• GitFlow 模型
• 短特性分支模式
• 单主干模型

三、GitFlow 模型

GitFlow 设计之初，主要是为了解决使用 Git 时，Git 提交记录杂乱无章的情况。

不难想象，每个人都随心所欲去提交自己的代码，项目很快就会变得难以协调和维护。

后面是 GitFlow 分支模型图：

从上图可以看出，开发人员主要都是基于 Develop 分支来开发的。

开发新的特性时，首先需要基于 Develop 分支拉取 Feature 分支，然后基于这个 Feature 分支实现特性开发，完成后合并入 Develop 分支。

当有版本需要发布时，就要基于 Develop 分支拉起对应的 Release 分支来做版本测试，验证成功后就会将代码合并到 Master 分支中，并打上 Tag 标记。

如果版本在线上运行时出现问题，会基于 Release 分支拉取 Hotfixes 分支并修复问题，修复完再将修改合并到主干和 Develop 分支中。

GitFlow 分支模型的特点是开发各自在特性分支上互不干扰地开发，特性分支可以长期存在，甚至跨越多个发布周期。

GitFlow 分支也有一些问题，比如日常提交分布在各条特性分支，无法及时集成和联调；特性分支生命周期太长，冲突风险增加。

四、短特性分支模型

那么如何来优化 GitFlow 长期特性分支带来的问题呢？

这就要说到第二种常用的分支模型——短特性分支模型。

短特性分支模型指的是所有的开发者都在主干上进行协作开发。

在这种模型下，为了保持灵活性，是不允许新建任何长期存在的开发分支的，但可以使用短的特性分支来持续集成。

后面是短特性分支模型图。

短特性分支模型的特点是使用周期非常短的特性分支，一般情况下，短特性分支的生命周期一般在 3 天左右，不超过 5 天，所有特性都会合并到主干。

另外，当线上版本需要修复 bug 时，会基于 Release 分支的 Tag 来修复 bug，修复记录需要同时合并到主干分支。

短特性分支模型需要配合其他敏捷实践一起使用，团队要提前规划固定节奏的发布计划，并且要将特性拆分成可以独立交付的小故事（任务）。

为了保证代码质量，则需要完善的代码审核和持续交付的流水线，且在合入主干前要先验证所提交代码的质量，通过流水线保证主干随时可发布（至少是测试版本）。

五、单主干分支模型

短特性分支已经可以很好帮助实现版本持续集成，但如果需要更加频繁地集成发布。

可以参考第三种分支模型——单主干分支模型。

单主干分支模型与短特性分支模型类似，关键的区别是单主干没有短的特性分支，有且只有 1 个开发分支，即主干分支，所有改动都发生在主干分支。

后面是单主干分支模型图。

单主干的挑战相比短特性分支模型更大，由于所有的特性都是直接合并到主干分支，所以对于代码合入质量、需求规划要求更高。

另外，在架构上需要支持使用抽象的“分支”或特性开关来屏蔽特性，从而保证主干上的功能能够灵活地配合规划发布相应的版本。

不过，单主干也有它的优点，由于没有临时开发分支，所有特性都能及时集成。

其模型简单，分支少，开发人员的切换成本低，所以单主干模式也是最符合持续集成的要求。

六、Sharing 分支模型设计

通常情况下，组件化的架构一般分为 2 个部分：

• 第一个部分是独立维护迭代的组件
• 另外一个部分是集成发布组件的基座。

分别来看看这 2 种类型的分支模型。因为组件会持续不断地演进新的功能，所以常常会出现一个版本内多个小特性同时开发的情况。所以建议组件分支模型可以考虑使用短特性分支模型。

在实践过程中，需要将需求拆分为各个小的特性或者任务，并且通过质量门禁来保障合入主干的代码质量。并且为了保护主干分支的质量，我们可以将主干分支设置为保护分支，所有合并入主干分支的代码需要提交 MR 或者 PR，经过人工代码检视后，再合入主干分支。对于集成的基座来说，通常代码提交只为配置需要发布的组件，然后集成发布组件。

所以对于集成基座的分支模型，可以考虑使用单主干分支模型。但在实践过程中，仍然可以利用版本管理工具的 MR 或者 PR 来人工 Reivew，但此时的临时分支仅仅只是为了做代码监视而已。

确定好产品的分支模型非常重要，因为后续的持续基础流水线都会基于分支来触发构建，可以根据不同的分支类型，针对性地设计流水线环节与质量门禁，为高效、高质量地发布软件版本保驾护航。

七、总结

分支的灵活性像是一条捷径，可以在研发过程中更方便地去做功能组合以及控制版本发布。但是如果缺少规范及约束，大量长期的分支会大大增加我们后期合并代码的工作量，所以“美酒虽好，但不能贪杯”。

因为对于分支来说，长期分支在本质上和持续集成背道而驰！分支一旦拉出，就意味着有分叉，没有及时集成代码。分叉的时间拖得越久，那么代码的差异可能就越大，最后合并的成本可能就越高。

如果没有重视及做好分支规范，可能会导致需要花费大量的时间及人力在做代码合并的工作。

3 种常用的分支模型：

• GitFlow
• 短特性分支
• 单主干

在实践中根据自己的产品以及团队规模来选择合适的分支模型。对于组件化架构的分支策略来说，组件分支模型可以参考使用短特性分支模式，集成基座的分支模型可以参考使用单主干分支模型。但是注意不管选择何种模型，仍然建议需要做好分支的规范以及管理，避免存在大量的长期并行分支。

如果团队短时间内无法统一分支模型，为了持续集成还可以在分支管理方面，做哪些努力呢？

总结了实践过程中拉取分支的六个要点。

1. 尽量少拉长期分支。
2. 尽量晚拉分支。
3. 分支尽早合并或删除。
4. 分支活跃期间要频繁同步。
5. 分支从哪里拉出来，就合并回哪里。
6. 主干分支必须保持随时可发布。