Git、GitHub、GitLab Flow，傻傻分不清？一图看懂各种分支管理模型

理论是灰色的，生命之树常青。

引言

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

背景

目前笔者所在的前端部门，技术栈是 React & RN 为主，Vue 为辅，也就是说 React 和 Vue 双栈共存，可以说是研发环境比较复杂了，运维部门也制定了相应的 git 管理模型，不过也是比较通用的，那么如何制定一个符合前端部门的 git 管理模型尤为重要，且不可与运维部门的管理模型相冲突，由此便诞生了此篇文章。

Git Flow

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

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

GitHub Flow

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

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

其大概的流程图如下：

图源 gaboesquivel.com

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

GitLab Flow

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

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

TrunkBased

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

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

OneFlow

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

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

AoneFlow

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

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

下面是其大致的流程图：

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

总结

介绍了众多的分支管理模型，那么我们该如何挑选适合自己团队的方案呢？在这里制作了一个思维导航图，详情如下：