很久以前我出過一個 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 也是一致的，在此基礎之上，其他的基本上沒有太多限制，比較自由。

審核編輯：符乾江