Git 实践，什么才是优秀的工作流？

很久以前我出过一个 Git 教程，小伙伴们要是还不懂 Git 的用法，可以在公众号底部菜单中，有一个教程合集，里边有 Git 教程的索引。

今天我们不聊基本用法，聊一聊 Git 到底应该怎么用?我们知道相比于 Svn，Git 最牛的地方在于它的分支，分支很灵活，但是如果缺乏一个使用套路，又会用的乱糟糟的，特别是在团队协作中，该怎么玩 Git 分支?

咱们也不发明什么轮子，也不设计什么全新流程，本文主要是和大家介绍三种常见的工作流：Git Flow、GitHub Flow 以及 GitLab Flow。介绍完成后，在谈谈松哥的一些使用体验。

1. Git 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。我们分别来看：

feature branches

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

hotfixes branches

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

release branches

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

大概就是这个意思。

松哥工作中用的其实就是类似于 Git Flow 的工作流，为什么说是类似呢?我们项目中主要是保证了 master、develop 以及 release 三个分支，在此基础之上，其他随意。

2. GitHub Flow

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

官方给的 GitHub Flow 流程如下：

它的流程是这样的：

• 需要开发新功能或者修复 BUG 的时候，从 master 上拉一个新的分支下来。
• 新的分支开发完成后，或者说当你遇到困难开发不下去的时候，都可以发起一个 pr(Pull Request)。
• pr 既提交代码，也让其他同事 review 你的代码，在这个过程中，你可以不断提交 pr。
• 最终你的 pr 被接受，合并进 master。

GitHub 工作流虽然用着很简单，但是他的问题也很明显，就是没有对常见的工作场景中的问题提出解决办法。

3. GitLab Flow

GitLab Flow 结合了 Git Flow 与 GitHub Flow 的优点，它不像 Git Flow 有那么多容易把新手绕晕的分支，同时它又可以适应不同的开发环境。

GitLab Flow 的最大原则叫做 upstream first，中文译作“上游优先”：即只存在一个主分支 master，它是所有其他分支的 upstream，只有上游分支采纳的代码变化，才能应用到其他分支。

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

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

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

有稳定的版本需要发布时，我们就从 master 上拉一个新的分支出来，作为发版时候的分支，这些分支上不要开发新功能，只有修补 BUG 的时候

对于”版本发布”的项目，建议的做法是每一个稳定版本，都要从master分支拉出一个分支，比如2-3-stable、2-4-stable等等。

以后，只有修补bug，才允许将代码合并到这些分支，并且此时要更新小版本号即可。

4. 小结

好啦这就是常见的三个 Git 玩转流程，其实我们自己开发不必这么死板，结合自己的项目来就行了，松哥的项目，master、develop 以及 release 三个分支是固定的，这三个分支的作用跟前面介绍的 Git Flow 也是一致的，在此基础之上，其他的基本上没有太多限制，比较自由。

参考资料：

https://www.cnblogs.com/sloong/p/5868292.html

https://medium.com/@lf2lf2111/%E4%B8%89%E7%A8%AE%E7%89%88%E6%8E%A7%E6%B5%81%E7%A8%8B-29c82f5d4469

https://cloud.tencent.com/developer/article/1646937

本文转载自微信公众号「江南一点雨」，可以通过以下二维码关注。转载本文请联系江南一点雨公众号。