精通Git--工作流

前言

在前面的文章中我已经提到过了关于工作流,而且当时建议大家去读 阮一峰 的 《Git 工作流程》, 由于这两天我再录制一个关于 Git 的系列视频 《让你彻底理解Git》, 那就把这块知识再次归纳整理一下,用于视频的参考文档。

什么是工作流

如果我们的工作是一条线进行,不会有发布后的修改,不会有版本回退,就只有向前开发,不断往进添加代码,这样就形成了一个最简单的工作流,一条线:

最简单都能理解的工作流

当然了,日常开发中我们遇到的问题远不是这么简单,例如:发布后发现出现了bug,需要修复, 实际业务分不同功能开发(分组开发)。所以就有人提出了一些能很好协作的使用 Git 分支的工作流程,这些流程能高效有序的让大家一起协作开发。而目前比较流行的有三种工作流程,每个都有它的侧重点,和它最合适的使用场景。

Git flow

Git flow 是最早诞生、并得到广泛采用的一种工作流程,这个是 Vincent Driessen 提出的。

首先,我们应该保证一个不会回退的 master 分支,这个分支上的代码永远是可以发布的。也就是说随时可以从这个分支打包发布。而且我们会给每一次发布打一个远程 tag 来区分不同版本的位置。

master 分支上不同版本 Tag

接下来,我们应该在一个新分支 develop 上面进行日常开发的代码提交。当然了这个 Git flow 工作流只是一个建议,所以我们在遵循这种思想的前提下应该更多的考虑实际开发情况进行适当修改,比如我们可以有两个 develop 分支来分别开发不同的功能组。

develop 分支上开发提交

如果我们开发到一定阶段,需要提交给测试,那么就需要创建一些临时分支了(临时分支就是用完可以直接删了的分支),假设我们创建的临时分支是 release 预发布分支(从 develop 分支创建 release 分支)。

release 分支上面修改bug 后合并到 master 和 develop

上图 绿色 部分是修复的 bug commit, 然后 虚线空心 是表示合并前不存在,合并后变成实心。 当然了,如果我们有多个分组,还有一种方案就是建多个临时功能分支 feature, 当功能完成后先合并到 develop 再进行上述操作。上面合并完后就可以删除 release 分支了。

接下来我们可能会遇到在向后开发过程中,我们发布的线上版本出现了 bug, 这个时候可以从 master 分支对应版本的 tag 处创建一个临时分支。

在 hotfix 分支修复bug

如上图 紫色 部分使我们修复的 bug commit, 合并后就可以删除 hotfix 分支了。当然你也可以从 hotfix 分支再创建一个临时分支 release 用于测试,边测试你再边修复其他 bug, 整个过程可以根据你的实际情况作出相应调整。

我们来大概总结一下,在 Git flow 中我们要维护两个长期分支 master 和 develop, 如果我们工作中频繁切换 master 和 develop 分支很麻烦,而且 master 和 develop 的代码比较一致,如果我们的项目是很频繁的发布,那使用它就比较繁琐了,如果我们的工程在很长一段时间不会发布,那么 master 和 develop 的分开就很有用,这个时候使用它很合适。

GitHub flow

上面的 Git flow 分支维护过程比较麻烦,如果不是特别大型,长时间才发布一个版本的项目其实并不合适,而 GitHub flow 正适合这种频繁进行版本发布的项目,它简化了分支。

在 GitHub flow 中只有一个长期分支 master, 和 Git flow 不同的是 GitHub 提供了一个 Pull Request(简称 PR)。也正是因为有了这个 PR 才使它可以只维持一个 master 分支而获得来自不同分支的合并请求。 而且这个 master 分支就是一个随时可以发布的版本,当然你也可以创建一个 deployed 分支用来合并正式发布版本的代码。

Github 不关心你创建了多少分支,最终都提交到 master

你可以试想一下,我们现在有很多非 master 分支要合并过来,这个时候就需要一个强大的请求应答机制,也就是其他分支通过 Pull Request 先通知所有人,让别人注意到自己的提交请求,这是一种对话机制,然后大家一起评审和讨论代码,在这个过程中也可以不断提交代码。

GitHub 的这种工作流最大的特点就是简单,对于那种持续发布的产品非常合适。

Gitlab flow

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

Gitlab flow 工作流提出了一个原则,叫 “上游优先”,而且同样的它只存在一个长期分支 master, 它是所有分支的上游,只有上游分支采纳的代码,才能应用到其他分支。

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

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

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