如何在足够规模团队中高效使用 Git 管理代码？

柔情只为你懂 2021-09-24 13:18 324阅读 0赞

用了 Git 多年，优势和挑战都是深有体会。

话不多说，直接上问题：如何在足够规模团队中高效使用 Git 管理代码？

继续不多话，直接上答案：分支管理。

Git 的分支管理有很多实践，有些是从 SVN 类的集中式版本管理工具继承的，有些是根据 Git 自己的特性总结的，目前市面上比较有名的三种 Git 分支管理模型是：

*  TrunkBased：主干在手，天下我有。所有代码都往主干上招呼，发版也只用主干。
 *  GitFlow：严谨、规范、难用，主要是记不住该往哪个分支合并了。
 *  AoneFlow：前两种都不行，那就借鉴各自的优点，达到阴阳平衡，中庸也。

## TrunkBased ##

TrunkBased，又叫主干开发，有一个网站专门介绍这种开发方式：[Trunk Based Development][]。

TrunkBased 是持续集成思想所崇尚的工作方式，它由单个主干分支和许多发布分支组成，每个发布分支在特定版本的提交点上从主干创建出来，用来进行上线部署和 Hotfix。在 TrunkBased 模式中，没有显性的特性分支。当然实际上 Git 的分布式特征天生允许每个人有本地分支，TrunkBased 也并非排斥短期的特性分支存在，只不过在说这种模式的时候，大家通常都不会明确强调它罢了。

![TrunkBased][]

使用主干开发后，我们的代码库原则上就只能有一个 Trunk 分支即 master 分支了，所有新功能的提交也都提交到 master 分支上，保证每次提交后 master 分支都是可随时发布的状态。没有了分支的代码隔离，测试和解决冲突都变得简单，持续集成也变得稳定了许多。

但是这种方案缺点也比较明显，如果大家都在主干进行开发，当代码提交合并时，将会异常痛苦，一不小心就会出现冲突。而且，这种因为这种方式没有明显的特性分支，想要移除已经上线的特性会变得非常困难。（如果你说把不要的功能注释，重新发版，那就当我什么也没说。）还有一种方案是引入特性开关，通过开关控制特性是否启用和关闭，但是增加开关就引入了复杂性，引入复杂性就引入了出 bug 的风险，毕竟多增加的每行代码都有可能是一个新的 bug。

## GitFlow ##

GitFlow 来源于 Vincent Driessen 提出的 [A successful Git branching model][]，整体来说，是一套完善的版本管理流程。缺点就是太过严格，不太适合喜欢自由而且懒的程序猿。当然，在程序猿这种物种中，没有完美的解决方案，总有那么一小撮人会觉得不好。参考 Ant、Maven 和 Gradle。

先上图：

![GitFlow：A successful Git branching model][GitFlow_A successful Git branching model]

GitFlow 常用分支：

*  主干分支（`master`）：最近发布到生产环境代码的分支，这个分支只能从其他分支合并，不能再 Master 分支直接修改。
 *  主开发分支（`develop`）：包含所有要发布到下一个 Release 版本的代码。可以在 Develop 直接开发，也可以将 Feature 的特性代码合并到 Develop 中。  
    ![主开发分支][format_png]
 *  特性分支（`feature/*`）：功能项开发分支，以`feature/`开头命名分支，当功能项开发完成，将被合并到主开发分支进入下一个 Release，合并完分支后一般会删点这个特性分支。  
    ![特性分支][format_png 1]
 *  发布分支（`release/*`）：基于主开发分支创建的一个发布分支，以`release/`开头命名分支，用于测试、bug 修复及上线。完成后，合并到主干分支和主开发分支，同时在主干分支上打个 Tag 记住 Release 版本号，然后可以删除发布分支。  
    ![发布分支][format_png 2]
 *  热修复分支（`hotfix/*`）：用于解决线上 Release 版本出现的 bug，以`hotfix/`开头命名分支，修复线上问题，完成后，合并到主干分支和主开发分支，同时在主干分支上打个 tag。  
    ![热修复分支][format_png 3]

根据上面描述，GitFlow 是一套完整的从开发到生产的管理方式，但是各种分支来回切换及合并，很容易把人搞晕，所以用的人也是越来越少。

## AoneFlow ##

AoneFlow 是阿里内部的一套版本管理模型，兼顾了 TrunkBased 易于持续集成和 GitFlow 易于管理需求的特点，又规避了 GitFlow 分支繁琐的缺点，也就是中庸。

AoneFlow 使用三个分支：主干分支（`master`）、特性分支（`feature/*`）、发布分支（`release/*`），以及三条原则：

**规则一，开始工作前，从主干分支创建特性分支。**

这条规则借鉴了 GitFlow，每当开始一件新的工作项（比如新的功能或是待解决的问题，可以是一个人完成，或是多个人协作完成）时，从代表最新已发布版本的主干分支上创建一个通常以`feature/`前缀命名的特性分支，然后在这个分支上提交代码修改。也就是说，每个工作项对应一个特性分支，所有的修改都不允许直接提交到主干。

![从主干创建特性分支][format_png 4]

特性分支不止承担了新功能，也是待解决问题的分支。对于我们团队，为了避免歧义，会将新功能以`feature/`为前缀，待解决问题以`hotfix/`为前缀，除了名称外，其他都按照规则一执行。

**规则二，通过合并特性分支，形成发布分支。**

GitFlow 先将已经完成的特性分支合并回主干分支和主开发分支，然后在主干分支上打 Tag 记录发布信息。TrunkBased 是等所有需要的特性都在主干分支上开发完成，然后从主干分支的特定位置拉出发布分支。而 AoneFlow 的思路是，从主干上拉出一条新分支，将所有本次要集成或发布的特性分支依次合并过去，从而得到发布分支，发布分支通常以`release/`前缀命名。

![合并特性分支，形成发布分支][format_png 5]

我们可以将每条发布分支与具体的环境相对应，`release/test`对应部署测试环境，`release/prod`对应线上正式环境等，并与流水线工具相结合，串联各个环境上的代码质量扫描和自动化测试关卡，将产出的部署包直接发布到相应环境上。

另外，发布分支的特性组成是动态的，调整起来特别容易。在一些市场瞬息万变的互联网企业，以及采用“敏捷运作”的乙方企业经常会遇到这种情况，已经完成就等待上线的需求，随时可能由于市场策略调整或者甲方的一个临时决定，其中某个功能忽然要求延迟发布或者干脆不要了。再或者是某个特性在上线前发现存在严重的开发问题，需要排除。按往常的做法，这时候就要来手工“剔代码”了，将已经合并到开发分支或者主干分支的相关提交一个个剔除出去，做过的同学都知道很麻烦。在 AoneFlow 模式下，重建发布分支，只需要将原本的发布分支删掉，从主干拉出新的同名发布分支，再把需要保留的各特性分支合并过来就搞定，而且代码是干净的，没有包含不必要的特性。

此外，发布分支之间是松耦合的，这样就可以有多个集成环境分别进行不同的特性组合的集成测试，也能方便的管理各个特性进入到不同环境上部署的时机。松耦合并不代表没有相关性，由于测试环境、集成环境、预发布环境、灰度环境和线上正式环境等发布流程通常是顺序进行的，在流程上可以要求只有通过前一环境验证的特性，才能传递到下一个环境做部署，形成漏斗形的特性发布流。当然，这种玩法比较适合有完整开发集成平台的公司，小团队玩不转，比如我们团队就玩不动这种高级玩法。

**规则三，发布到线上正式环境后，合并相应的发布分支到主干，在主干添加 Tag，同时删除该发布分支关联的特性分支。**

当一条发布分支上的流水线完成了一次线上正式环境的部署，就意味着相应的功能真正的发布了，此时应该将这条发布分支合并到主干。为了避免在代码仓库里堆积大量历史上的特性分支，还应该清理掉已经上线部分特性分支。与 GitFlow 相似，主干分支上的最新版本始终与线上版本一致，如果要回溯历史版本，只需在主干分支上找到相应的版本标签即可。

![合并相应的发布分支到主干，在主干添加 Tag，同时删除该发布分支关联的特性分支][Tag]

除了基本规则，还有一些实际操作中不成文的技巧。比如上线后的热修复，正常的处理方法应该是，创建一条新的发布分支，对应线上环境（相当于 Hotfix 分支），同时为这个分支创建临时流水线，以保障必要的发布前检查和冒烟测试能够自动执行。

## 再啰嗦几句废话 ##

不管哪种方式，既然存在，都会有一定合理性。所以，不管最终翻了哪个牌子，不是因为这个好看，而是因为这个更适合自己。

--------------------

个人主页：[https://www.howardliu.cn][https_www.howardliu.cn]  
个人博文：[如何在足够规模团队中高效使用 Git 管理代码？][Git]  
CSDN 主页：[http://blog.csdn.net/liuxinghao][http_blog.csdn.net_liuxinghao]  
CSDN 博文：[如何在足够规模团队中高效使用 Git 管理代码？][Git 1]

[Trunk Based Development]: https://trunkbaseddevelopment.com/
[TrunkBased]: /images/20210923/4daac36e4e114040bbd510a9d9242596.png
[A successful Git branching model]: https://nvie.com/posts/a-successful-git-branching-model/
[GitFlow_A successful Git branching model]: /images/20210923/6d8455a63f1c4dac93ab30fa3ea8abff.png
[format_png]: /images/20210923/5904b4f4cd8d43ddbeb1156d5fe44f04.png
[format_png 1]: /images/20210923/a5b75f5ea5174091a8eb6882948981ed.png
[format_png 2]: /images/20210923/ce5eeb546eb046668f956d5f3b3e0308.png
[format_png 3]: /images/20210923/6d632c927a584f50a8c5d2d493f6b9d3.png
[format_png 4]: /images/20210923/8c63cc15bbd648fe93b8e3170457ed91.png
[format_png 5]: /images/20210923/258f611ab5ae42729cf4edce9b1be44e.png
[Tag]: /images/20210923/853f0802e1884aaab1a6a76d1fc0b8bc.png
[https_www.howardliu.cn]: https://www.howardliu.cn
[Git]: https://www.howardliu.cn/how-to-use-branch-efficiently-in-git/
[http_blog.csdn.net_liuxinghao]: http://blog.csdn.net/liuxinghao
[Git 1]: https://blog.csdn.net/liuxinghao/article/details/103794938