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

图解六种分支管理模型

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

1.Git Flow

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

优点:分支管理严格,代码合并清晰,适合于中大型团队应用。

缺点:分支流程过多反而也是一种缺点。

2.GitHub Flow

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

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

其大概的流程图如下:

优点:分支足够简单,且符合人类思维逻辑,适用于持续发布场景。

缺点:针对多版本产品线则不适用。

3.GitLab Flow

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

优点:git 提交历史更加清晰、简洁与易读。

缺点:对开发人员的能力提出了更高的要求,当存在多产品线时,和 Git Flow 相比平分秋色。

4.TrunkBased

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

优点:简单清晰,单兵作战最佳选择,适合维护后期超稳定的项目。

缺点:不适用多版本共存的项目。

5.OneFlow

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

优点:单一版本首选,git 提交历史简介清晰易读。

缺点:不适合持续交付或持续部署的项目,也不适用多版本共存的项目。

6.AoneFlow

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

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

下面是其大致的流程图:

优点:灵活易用,通过组合生成分支往往可以实现多种高级玩法。

缺点:复杂度稍高,如果没有配套的工具规范往往会出现 无效分支 的出现。

7.总结

相关推荐
杨杨杨大侠6 分钟前
第6章:高级特性与性能优化
java·github·eventbus
澈轩32 分钟前
Git 用得好,下班走得早
git
HelloGitHub34 分钟前
这款开源调研系统越来越“懂事”了
前端·开源·github
ruanCat38 分钟前
配置 github workflow 工作流文件,实现仓库自动更新 github page 站点
github
绝无仅有1 小时前
面试总结之Nginx 经验常见问题汇总第二篇
后端·面试·github
绝无仅有2 小时前
面试实战总结之Nginx配置经验第一篇
后端·面试·github
掘金安东尼2 小时前
Chrome 17 岁了——我们的浏览器简史
前端·javascript·github
人间造梦工厂2 小时前
Git Bash 别名
git
画个太阳作晴天7 小时前
解决 Android Studio 中 build 目录已被 Git 跟踪后的忽略问题
git
wjs04011 小时前
Git常用的命令
java·git·gitlab