理论是灰色的，生命之树常青。
引言
任何一家公司乃至于一个小组织，只要有写代码的地方，就有代码版本管理的主场，初入职场，总会遇到第一个拦路虎 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 条原则：
master分支永远是随时可部署发布的- 需求新增基于
master分支，并创建一个语义化分支 - 定期推送本地分支到远端
- 合并到
master需要提PR PR一旦经过code review无误后即可合并到mastermaster一旦接收到合并请求，即可立即部署发布
其大概的流程图如下：
优点：分支足够简单，且符合人类思维逻辑，适用于持续发布场景
缺点：针对多版本产品线则不适用
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] a-successful-git-branching-model
[2] githubflow
[3] what-are-gitlab-flow-best-practices
[4] oneflow-a-git-branching-model-and-workflow
[5] 在阿里，我们如何管理代码分支？