Git工作流

一、Git常见工作流

Git三种常见的工作流：Git Flow、GitHub Flow 、GitLab Flow

二、Git Flow

Git Flow 是最早诞生也是最早被广泛使用的工作流程。

在 Git Flow 中，有两个长期存在且不会被删除的分支：master 和 develop。

在这两个分支中，master 主要用于对外发布稳定的新版本，该分支时常保持着软件可以正常运行的状态，由于要维护这一状态，所以不允许开发者直接对 master 分支的代码进行修改和提交，其他分支的开发工作进展到可以发布的程度后，将会与 master 分支进行合并，并且这一合并只在发版时进行，发布时将会附加版本编号的 Git 标签。

develop 则用来存放我们最新开发的代码，这个分支是我们开发过程中代码中心分支，这个分支也不允许开发者直接进行修改和提交。程序员要以 develop 分支为起点新建 feature 分支，在 feature 分支中进行新功能的开发或者代码的修正，也就是说 develop 分支维系着开发过程中的最新代码，以便程序员创建 feature 分支进行自己的工作。

注意 develop 合并的时候，不要使用 fast-farward merge，建议加上 --no-ff 参数，这样在 master 上就会有合并记录，关于这两个的区别，大家可以参数松哥之前的 Git 教程，这里不再赘述。

除了这两个永久分支，还有三个临时分支：feature branches、hotfixes 以及 release branches。我们分别来看。

2.1 feature branches

这个是特性分支，也叫功能分支，当你需要开发一个新的功能的时候，可以新建一个 feature-xxx 的分支，在里边开发新功能，这也是我们日常工作的大本营，开发完成后，将之并入 develop 分支中，如下图：

1

2.2 hotfixes branches

这个分支看名字就是用来修复 BUG 的，当我们的项目上线后，发现有 BUG 需要修复，那么就从 Master 上拉一个名为 fixbug-xxx 的分支，然后进行 BUG 修复，修复完成后，再将代码合并到 Master 和 Develop 两个分支中，然后删除 hotfix 分支，如下图：

2

2.3 release branches

这个是发版的时候拉的分支，当我们所有的功能做完之后，准备要将代码合并到 master 的时候，从 develop 上拉一个 release-xxx 分支出来，这个分支一般处理发版前的一些提交以及客户体验之后小 BUG 的修复（BUG 修复后也可以将之合并进 develop），不要在这个里边去开发功能，在预发布结束后，将该分支合并进 develop 以及 master，然后删除 release，如下图：

3

三、GitHub Flow

GitHub Flow 相比于 Git Flow 就要容易很多了，GitHub Flow 也是 GitHub 上使用的工作流程，如果你想参与 GitHub 上的某一个开源项目，那么不妨看看 GitHub Flow。官方给的 GitHub Flow 流程如下：

4

• 第一步：根据需求，从master拉出新分支，不区分功能分支或补丁分支。
• 第二步：新分支开发完成后，或者需要讨论的时候，就向master发起一个pull request（简称PR）。
• 第三步：Pull Request既是一个通知，让别人注意到你的请求，又是一种对话机制，大家一起评审和讨论你的代码。对话过程中，你还可以不断提交代码。
• 第四步：你的Pull Request被接受，合并进master，重新部署后，原来你拉出来的那个分支就被删除。（先部署再合并也可。）

GitHub 工作流虽然用着很简单，但是他的问题也很明显，就是没有对常见的工作场景中的问题提出解决办法。GitHub Flow这种方式，要保证高质量，对于贡献者的素质要求很高，换句话说，如果代码贡献者素质不那么高，质量就无法得到保证。

四、GitLab Flow

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

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

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

5

只有紧急情况，才允许跳过上游，直接合并到下游分支。对于”版本发布”的项目，建议的做法是每一个稳定版本，都要从master分支拉出一个分支，比如2-3-stable、2-4-stable等等。

6

GitLab flow 如何处理hotfix？ Git Flow之所以这么复杂，一大半原因就是把hotfix考虑得太周全了。hotfix的意思是，当代码部署到产品环境之后发现的问题，需要火速fix。GitLab Flow 可以基于后续分支，修改后上线。

4.1 采用GitLab Flow工作流程

• 新的迭代开始，所有开发人员从主干master拉个人分支开发特性, 分支命名规范 feature-name

• 开发完成后，在迭代结束前，合入master分支

• master分支合并后，自动cicd到dev环境

• 开发自测通过后，从master拉取要发布的分支，release-$version，将这个分支部署到测试环境进行测试

• 测出的bug，通过从release-$version拉出分支进行修复，修复完成后，再合入release-$version

• 正式发布版本，如果上线后，又有bug，根据5的方式处理

• 等发布版本稳定后，将release-$version反合入主干

转载自：Git 最佳实践，什么才是最佳工作流？