实践是灰色的，生命之树常青。
引言
任何一家公司乃至于一个小组织，只有有写代码的中央，就有代码版本治理的主场，初入职场，总会遇到第一个拦路虎 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一旦接管到合并申请，即可立刻部署公布
其大略的流程图如下：\
图源 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] a-successful-git-branching-model
[2] githubflow
[3] what-are-gitlab-flow-best-practices
[4] oneflow-a-git-branching-model-and-workflow
[5] 在阿里，咱们如何治理代码分支？