图解六种分支管理模型
任何一家公司乃至于一个小组织,只要有写代码的地方,就有代码版本管理的主场,初入职场,总会遇到第一个拦路虎 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
由阿里巴巴技术专家林帆基于 TrunkBased
和 GitFlow
提出的一种新改进,其主要分为三种分支类型:主干分支、特性分支 以及 发布分支,并且提出了三个基本准则:
- 主干创建特性分支,且不允许合并回主干分支。
- 合并特性分支,形成发布分支。
- 发布到线上正式环境后,合并相应的发布分支到主干,在主干添加标签,同时删除该发布分支关联的特性分支。
下面是其大致的流程图:
优点:灵活易用,通过组合生成分支往往可以实现多种高级玩法。
缺点:复杂度稍高,如果没有配套的工具规范往往会出现 无效分支 的出现。