高效的Gitlab Flow最佳实践

文章目录

一、git flow
二、github flow
三、gitlab flow
四、基于gitlab flow的最佳实践
- 1.语义化版本号
- 2.测试发布
- 3.bug修复
参考

业界包含三种flow：

Git flow
Github flow
Gitlab flow

三种工作流程，有一个共同点：都采用"功能驱动式开发"（Feature-driven development，简称FDD）。

它指的是，需求是开发的起点，先有需求再有功能分支（feature branch）或者补丁分支（hotfix branch）。完成开发后，该分支就合并到主分支，然后被删除。

一、git flow

最早诞生、并得到广泛采用的一种工作流程，就是Git flow 。
在这里插入图片描述

首先，项目存在两个长期分支。

主分支master
开发分支develop

前者用于存放对外发布的版本，任何时候在这个分支拿到的，都是稳定的分布版；后者用于日常开发，存放最新的开发版。

其次，项目存在三种短期分支。

功能分支（feature branch）
补丁分支（hotfix branch）
预发分支（release branch）

一旦完成开发，它们就会被合并进develop或master，然后被删除。

缺点：

单独使用 git flow 命令管理

sudo apt-get install git-flow -y

综合考虑了开发、测试、新功能开发、临时需求、热修复，理想很丰满，现实很骨干，这一套运行起来实在是太复杂了。

二、github flow

它只有一个长期分支，就是master，因此用起来非常简单。

官方推荐的流程如下：
在这里插入图片描述

第一步：根据需求，从master拉出新分支，不区分功能分支或补丁分支。

第二步：新分支开发完成后，或者需要讨论的时候，就向master发起一个pull request（简称PR）。

第三步：Pull Request既是一个通知，让别人注意到你的请求，又是一种对话机制，大家一起评审和讨论你的代码。对话过程中，你还可以不断提交代码。

第四步：你的Pull Request被接受，合并进master，重新部署后，原来你拉出来的那个分支就被删除。（先部署再合并也可。）

缺点：

github flow这种方式，要保证高质量，对于贡献者的素质要求很高，换句话说，如果代码贡献者素质不那么高，质量就无法得到保证。

三、gitlab flow

Gitlab flow 是 Git flow 与 Github flow 的综合。它吸取了两者的优点，既有适应不同开发环境的弹性，又有单一主分支的简单和便利。它是 Gitlab.com 推荐的做法。

（1）上游优先
Gitlab flow 的最大原则叫做"上游优先"（upsteam first），即只存在一个主分支master，它是所有其他分支的"上游"。只有上游分支采纳的代码变化，才能应用到其他分支。

Chromium项目就是一个例子，它明确规定，上游分支依次为：

Linus Torvalds的分支
子系统（比如netdev）的分支
设备厂商（比如三星）的分支

（2）持续发布
Gitlab flow 分成两种情况，适应不同的开发流程。
在这里插入图片描述

对于"持续发布"的项目，它建议在master分支以外，再建立不同的环境分支。比如，"开发环境"的分支是master，"预发环境"的分支是pre-production，"生产环境"的分支是production。

开发分支是预发分支的"上游"，预发分支又是生产分支的"上游"。代码的变化，必须由"上游"向"下游"发展。比如，生产环境出现了bug，这时就要新建一个功能分支，先把它合并到master，确认没有问题，再cherry-pick到pre-production，这一步也没有问题，才进入production。

只有紧急情况，才允许跳过上游，直接合并到下游分支。

（3）版本发布
在这里插入图片描述