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 是什麼？為什麼需要這種東西？