【CI/CD】图解六种分支管理模型

图解六种分支管理模型

任何一家公司乃至于一个小组织，只要有写代码的地方，就有代码版本管理的主场，初入职场，总会遇到第一个拦路虎 git 管理流程，但是每一个企业似乎都有自己的 git 管理流程，倘若我们能掌握常用的 git 分支管理模型，那么无论碰到什么样的 git 管理流程，只不过都是这些管理模型的衍生与简化而已。

1.Git Flow

著名大佬 Vincent Driessen 在《A successful Git branching model》一文提出了影响深远的 git 代码管理模型，现如今依然许多中大型企业在沿用，下面是他提出的流程图：

优点：分支管理严格，代码合并清晰，适合于中大型团队应用。
缺点：分支流程过多反而也是一种缺点。

2.GitHub Flow

GitHub 于 $2011$ 年创建，遵循以下 $6$ 条原则：

• master 分支永远是随时可部署发布的。
• 需求新增基于 master 分支，并创建一个语义化分支。
• 定期推送本地分支到远端。
• 合并到 master 需要提 PR。
• PR 一旦经过 code review 无误后即可合并到 master。
• master 一旦接收到合并请求，即可立即部署发布。

其大概的流程图如下：

优点：分支足够简单，且符合人类思维逻辑，适用于持续发布场景。
缺点：针对多版本产品线则不适用。

3.GitLab Flow

GitLab 在 $2014$ 年提出 $11$ 条最佳实践，其相对 GitHub 增加了环境分支，且代码必须由上游（master）向下游（staging）发展，并且针对持续发布和版本发布都提出了相应的准则，下面是其大致流程图：

优点：git 提交历史更加清晰、简洁与易读。
缺点：对开发人员的能力提出了更高的要求，当存在多产品线时，和 Git Flow 相比平分秋色。

4.TrunkBased

研发团队只在 master 分支进行功能开发，当达到发布的条件时，直接迁出一个只读分支发布，只读分支顾名思义就是不接收任何新代码合并，以及在只读分支上进行修改；当研发人员相对较多时则可以使用 可扩展版本，增加了功能分支，但是功能分支不超过两三天则必须要合并到 master 分支，其大致的流程图如下：

优点：简单清晰，单兵作战最佳选择，适合维护后期超稳定的项目。
缺点：不适用多版本共存的项目。

5.OneFlow

Adam Ruka 于 2017 年提出，可以简单的理解为 Git Flow 的简化版本，除了 develop 开发分支和最新发布 master 分支，其余皆是临时分支，一旦开发完成即可删除临时分支，其中具体细则可查看这里，下面是其大致流程图：

优点：单一版本首选，git 提交历史简介清晰易读。
缺点：不适合持续交付或持续部署的项目，也不适用多版本共存的项目。

6.AoneFlow

由阿里巴巴技术专家林帆基于 TrunkBased 和 GitFlow 提出的一种新改进，其主要分为三种分支类型：主干分支、特性分支 以及 发布分支，并且提出了三个基本准则：

• 主干创建特性分支，且不允许合并回主干分支。
• 合并特性分支，形成发布分支。
• 发布到线上正式环境后，合并相应的发布分支到主干，在主干添加标签，同时删除该发布分支关联的特性分支。

下面是其大致的流程图：

优点：灵活易用，通过组合生成分支往往可以实现多种高级玩法。
缺点：复杂度稍高，如果没有配套的工具规范往往会出现 无效分支 的出现。

7.总结