很久以前我出过一个 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 分支中,如下图:

Git 最|佳实践,什么才是最|佳工作流?_git

hotfixes branches

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

Git 最|佳实践,什么才是最|佳工作流?_上拉_02

release branches

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

Git 最|佳实践,什么才是最|佳工作流?_github_03

大概就是这个意思。

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

2. GitHub Flow

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

官方给的 GitHub Flow 流程如下:

Git 最|佳实践,什么才是最|佳工作流?_git_04

它的流程是这样的:

  1. 需要开发新功能或者修复 BUG 的时候,从 master 上拉一个新的分支下来。
  2. 新的分支开发完成后,或者说当你遇到困难开发不下去的时候,都可以发起一个 pr(Pull Request)。
  3. pr 既提交代码,也让其他同事 review 你的代码,在这个过程中,你可以不断提交 pr。
  4. 最终你的 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,如下图:

Git 最|佳实践,什么才是最|佳工作流?_github_05

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

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

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

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

4. 小结

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

参考资料:

  • 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