乐趣区

关于git:Git-最佳实践什么才是最佳工作流

jiezi

很久以前我出过一个 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 流程如下：

它的流程是这样的：

  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，如下图：

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

有稳固的版本须要公布时，咱们就从 master 上拉一个新的分支进去，作为发版时候的分支，这些分支上不要开发新性能，只有修补 BUG 的时候

对于”版本公布”的我的项目，倡议的做法是每一个稳固版本，都要从 master 分支拉出一个分支，比方 2 -3-stable、2-4-stable 等等。

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

4. 小结

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

参考资料：

  • https://www.cnblogs.com/sloon…
  • https://medium.com/@lf2lf2111…
  • https://cloud.tencent.com/dev…
退出移动版