Git Flow 的缺點可以參考 git flow 實戰經驗談 part1 - 別再讓 gitflow 拖累團隊的開發速度這篇文章，裡面很詳細的解釋 Git Flow 的缺點，我從文章中節錄了幾個 Git Flow 缺點：

• gitflow 將流程建立在 develop 之上是不必要的，也是所有問題的根源，應單純以 master 為主。
• gitflow 要求 hotfix 及 release 需要分別 merge 進去 master 及 develop。這個想法製造了相當多不必要的 merge 動作。這邊正確的原則應跟前一點一樣，全部透過 master 來同步比較簡潔。
• 從尚未出版的 develop 建立分支，有可能會造成在每次出版週期中應該各自獨立的分支間產生不必要的相依性。
• develop 分支是由 master 長出來的，所以不要再有 master 不能 merge 進去 develop 這種想法。

創建 Git Flow 的作者說：GitHub Flow 是更簡單好用的流程，而官方給予的解釋如下：

GitHub flow is a lightweight, branch-based workflow that supports teams and projects where deployments are made regularly. This guide explains how and why GitHub flow works.

其實 GitHub Flow 和 Git Flow 最大的差異在於不需要一次建立 5 個分支，而是在需要這個功能時，再創建 feature 分支，經過一個 SOP 確認完沒問題後，再 merge 到 Master 分支上。而且在 GitHub Flow 中 Master 是可以被部署的，不像 Git Flow 是不能動的版本。

那麼，上述說的 SOP 是什麼呢？

圖片從 GitHub Guides 改編

如上圖，主要可以分成 6 個步驟，分別為：

• Create a branch
• Add commits
• Open a Pull Request
• Discuss and review your code
• Deploy
• Merge

GitHub Flow SOP

Create a branch

當你想要建立一個新的功能或是修改時，就新增一個分支，在通過 Deploy 前這個分支上的修改不會影響到 Master 上的程式。

而官方也有提到：There's only one rule: anything in the main branch is always deployable.

所以無論你是要新增、修補功能都可以從 Master 分支上拉出，而且命名要具有可讀性，這樣團隊的其他人才會知道這條分支是在負責什麼樣的事情。

Add commits

創建分支後就可以開始進行修改了！而每次在進行修改、新增、刪除都是在進行 commit 這個動作，這些 commit 也都會被記錄到你的 branch 下。
˙是
commit 的內容也很重要，就像程式碼的註解一樣，可以讓團隊成員更快看懂你這個分支主要在進行什麼任務，增加可讀性。

Open a Pull Request

當你完成任務後想要 merge 回 Master 就要先發起 Pull Request(簡稱：PR)，這個功能在 Fork 篇有提及過，所以就不贅述了，主要就是要發起 PR 等待對方同意你的 branch merge 到 Master 這樣。

Discuss and review your code

當你發起 Pull Request 後，團隊的成員或許會對你的程式有問題，這時就可以一起討論有疑問的部分，並且再進行修改。

Deploy

或許你更常聽到的是他的中文名字「部署」，就是在合併之前再進行一次最終測試，以免發生問題。

Merge

當上述流程都完成後，就可以 Merge 回 Master 了！
Merge 後會保留對程式的修改紀錄，以供未來參考使用。

上述就是 GitHub Flow 的整個流程，相較於 Git Flow 而言減少了許多分支的定義，更輕量化、簡單易懂。

Reference

git flow 實戰經驗談 part1 - 別再讓 gitflow 拖累團隊的開發速度
Understanding the GitHub flow