【Day18】Git 版本控制 - 多人协作 Git Flow

Okay! 了解 fork 跟 pull request 的运作原理後，接下来我们来谈谈 Flow 吧！

当一个团队共同开发专案时，因为每个人的习惯不同，发 commit 的方式也会不一样，倘若没有事先定义好一个 SOP 这个版本控制就会变得乱七八糟，因此，在 2010 年时由 Vincent Driessen 提出一套流程：A successful Git branching model

接下来，我们简单介绍一下 Vincent Driessen 的 Git Flow 到底是什麽

简单来说，这个 Git Flow 定义了五种分支，其中有两条分支是永久留存的，分别是：主分支（Master） 以及 开发分支（Develop）；而另外三条则是临时性的分支，分别为：功能分支（feature branch） 、 修复分支（hotfix branch） 、 预发分支（release branch），这三条分支是当被 merge 进 Master 或 Develop 後就会被删除的分支。

Master(主分支)

这个分支主要是拿来放稳定的、上线中的版本，通常不会直接 commit 到这个分支上，而是在别的分支测试到稳定後才会 merge 到这个 branch 上。

Develop(开发分支)

用来存放最新开发版本的分支，所有新的功能都会先 merge 到这个分支，当测试到稳定後才会 merge 到别的分支上。

feature branch(功能分支)

顾名思义，就是当要新增功能时就会使用这条分支，然後再 merge 到 Develop 上。

hotfix branch(修复分支)

这条分支比较特别，是从 Master 拉出来使用的，主要用途是当上线中的版本临时出现问题时，紧急进行修复用的。

release branch(预发分支)

这个分支是当 Develop 测试到差不多後，就可以合并到 Release 上，在合并到 Master 前再测试一次的概念，测试没问题後，就可以 merge 到 Develop 跟 Master 上。

看起来 Git Flow 是一个很完善的 SOP 对吧！但是该作者却在 2020 年发布一篇反思笔记：

Note of reflection (March 5, 2020)
This model was conceived in 2010, now more than 10 years ago, and not very long after Git itself came into being. In those 10 years, git-flow (the branching model laid out in this article) has become hugely popular in many a software team to the point where people have started treating it like a standard of sorts — but unfortunately also as a dogma or panacea.

During those 10 years, Git itself has taken the world by a storm, and the most popular type of software that is being developed with Git is shifting more towards web apps — at least in my filter bubble. Web apps are typically continuously delivered, not rolled back, and you don't have to support multiple versions of the software running in the wild.

This is not the class of software that I had in mind when I wrote the blog post 10 years ago. If your team is doing continuous delivery of software, I would suggest to adopt a much simpler workflow (like GitHub flow) instead of trying to shoehorn git-flow into your team.

If, however, you are building software that is explicitly versioned, or if you need to support multiple versions of your software in the wild, then git-flow may still be as good of a fit to your team as it has been to people in the last 10 years. In that case, please read on.

简单来说，就是作者认为 Git Flow 已经发展十年，甚至被当成圣经、教材使用，但时代的演变 Git Flow 也不再是那麽明确的 SOP 了，反而有更加简单的工作流程（像是 GitHub Flow）可以供使用，所以我们下一篇文章就来讲「什麽是 GitHub Flow」吧！

另外，我很喜欢作者的最後一段话，以下分享给大家～

To conclude, always remember that panaceas don't exist. Consider your own context. Don't be hating. Decide for yourself.

Reference

A successful Git branching model
Git Flow 是什麽？为什麽需要这种东西？