Java教程

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

本文主要是介绍Git、GitHub、GitLab Flow,傻傻分不清?一图看懂各种分支管理模型,对大家解决编程问题具有一定的参考价值,需要的程序猿们随着小编来一起学习吧!

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

引言

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

背景

目前笔者所在的前端部门,技术栈是 React & RN 为主,Vue 为辅,也就是说 ReactVue 双栈共存,可以说是研发环境比较复杂了,运维部门也制定了相应的 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 分支,其大致的流程图如下:

TrunkBased.png

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

OneFlow

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

OneFlow.png

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

AoneFlow

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

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

下面是其大致的流程图:

AoneFlow.png

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

总结

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

guideFlow.png

这篇关于Git、GitHub、GitLab Flow,傻傻分不清?一图看懂各种分支管理模型的文章就介绍到这儿,希望我们推荐的文章对大家有所帮助,也希望大家多多支持为之网!