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

图解六种分支管理模型

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

1.Git Flow

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

【CI/CD】图解六种分支管理模型_第1张图片
优点:分支管理严格,代码合并清晰,适合于中大型团队应用。
缺点:分支流程过多反而也是一种缺点。

2.GitHub Flow

GitHub 2011 2011 2011 年创建,遵循以下 6 6 6 条原则:

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

其大概的流程图如下:
【CI/CD】图解六种分支管理模型_第2张图片
优点:分支足够简单,且符合人类思维逻辑,适用于持续发布场景。
缺点:针对多版本产品线则不适用。

3.GitLab Flow

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

【CI/CD】图解六种分支管理模型_第3张图片
优点:git 提交历史更加清晰、简洁与易读。
缺点:对开发人员的能力提出了更高的要求,当存在多产品线时,和 Git Flow 相比平分秋色。

4.TrunkBased

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

【CI/CD】图解六种分支管理模型_第4张图片
优点:简单清晰,单兵作战最佳选择,适合维护后期超稳定的项目。
缺点:不适用多版本共存的项目。

5.OneFlow

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

【CI/CD】图解六种分支管理模型_第5张图片
优点:单一版本首选,git 提交历史简介清晰易读。
缺点:不适合持续交付或持续部署的项目,也不适用多版本共存的项目。

6.AoneFlow

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

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

下面是其大致的流程图:

【CI/CD】图解六种分支管理模型_第6张图片
优点:灵活易用,通过组合生成分支往往可以实现多种高级玩法。
缺点:复杂度稍高,如果没有配套的工具规范往往会出现 无效分支 的出现。

7.总结

【CI/CD】图解六种分支管理模型_第7张图片

你可能感兴趣的:(CI/CD,ci/cd,git,github,分支管理,版本管理)