很久以前我出過(guò)一個(gè) Git 教程，小伙伴們要是還不懂 Git 的用法，可以在公眾號(hào)底部菜單中，有一個(gè)教程合集，里邊有 Git 教程的索引。

今天我們不聊基本用法，聊一聊 Git 到底應(yīng)該怎么用？我們知道相比于 Svn，Git 最牛的地方在于它的分支，分支很靈活，但是如果缺乏一個(gè)使用套路，又會(huì)用的亂糟糟的，特別是在團(tuán)隊(duì)協(xié)作中，該怎么玩 Git 分支？

咱們也不發(fā)明什么輪子，也不設(shè)計(jì)什么全新流程，本文主要是和大家介紹三種常見(jiàn)的工作流：Git Flow、GitHub Flow 以及 GitLab Flow。介紹完成后，在談?wù)勊筛绲囊恍┦褂皿w驗(yàn)。

1. Git Flow

先來(lái)看 Git Flow。

Git Flow 是最早誕生也是最早被廣泛使用的工作流程。

在 Git Flow 中，有兩個(gè)長(zhǎng)期存在且不會(huì)被刪除的分支：master 和 develop。

在這兩個(gè)分支中，master 主要用于對(duì)外發(fā)布穩(wěn)定的新版本，該分支時(shí)常保持著軟件可以正常運(yùn)行的狀態(tài)，由于要維護(hù)這一狀態(tài)，所以不允許開(kāi)發(fā)者直接對(duì) master 分支的代碼進(jìn)行修改和提交，其他分支的開(kāi)發(fā)工作進(jìn)展到可以發(fā)布的程度后，將會(huì)與 master 分支進(jìn)行合并，并且這一合并只在發(fā)版時(shí)進(jìn)行，發(fā)布時(shí)將會(huì)附加版本編號(hào)的 Git 標(biāo)簽。

develop 則用來(lái)存放我們最新開(kāi)發(fā)的代碼，這個(gè)分支是我們開(kāi)發(fā)過(guò)程中代碼中心分支，這個(gè)分支也不允許開(kāi)發(fā)者直接進(jìn)行修改和提交。程序員要以 develop 分支為起點(diǎn)新建 feature 分支，在 feature 分支中進(jìn)行新功能的開(kāi)發(fā)或者代碼的修正，也就是說(shuō) develop 分支維系著開(kāi)發(fā)過(guò)程中的最新代碼，以便程序員創(chuàng)建 feature 分支進(jìn)行自己的工作。

注意 develop 合并的時(shí)候，不要使用 fast-farward merge，建議加上 --no-ff 參數(shù)，這樣在 master 上就會(huì)有合并記錄，關(guān)于這兩個(gè)的區(qū)別，大家可以參數(shù)松哥之前的 Git 教程，這里不再贅述。

除了這兩個(gè)永久分支，還有三個(gè)臨時(shí)分支：feature branches、hotfixes 以及 release branches。我們分別來(lái)看：

feature branches

這個(gè)是特性分支，也叫功能分支，當(dāng)你需要開(kāi)發(fā)一個(gè)新的功能的時(shí)候，可以新建一個(gè) feature-xxx 的分支，在里邊開(kāi)發(fā)新功能，這也是我們?nèi)粘９ぷ鞯拇蟊緺I(yíng)，開(kāi)發(fā)完成后，將之并入 develop 分支中，如下圖：

hotfixes branches

這個(gè)分支看名字就是用來(lái)修復(fù) BUG 的，當(dāng)我們的項(xiàng)目上線后，發(fā)現(xiàn)有 BUG 需要修復(fù)，那么就從 Master 上拉一個(gè)名為 fixbug-xxx 的分支，然后進(jìn)行 BUG 修復(fù)，修復(fù)完成后，再將代碼合并到 Master 和 Develop 兩個(gè)分支中，然后刪除 hotfix 分支，如下圖：

release branches

這個(gè)是發(fā)版的時(shí)候拉的分支，當(dāng)我們所有的功能做完之后，準(zhǔn)備要將代碼合并到 master 的時(shí)候，從 develop 上拉一個(gè) release-xxx 分支出來(lái)，這個(gè)分支一般處理發(fā)版前的一些提交以及客戶體驗(yàn)之后小 BUG 的修復(fù)（BUG 修復(fù)后也可以將之合并進(jìn) develop），不要在這個(gè)里邊去開(kāi)發(fā)功能，在預(yù)發(fā)布結(jié)束后，將該分支合并進(jìn) develop 以及 master，然后刪除 release，如下圖：

大概就是這個(gè)意思。

松哥工作中用的其實(shí)就是類(lèi)似于 Git Flow 的工作流，為什么說(shuō)是類(lèi)似呢？我們項(xiàng)目中主要是保證了 master、develop 以及 release 三個(gè)分支，在此基礎(chǔ)之上，其他隨意。

2. GitHub Flow

GitHub Flow 相比于 Git Flow 就要容易很多了，GitHub Flow 也是 GitHub 上使用的工作流程，如果你想?yún)⑴c GitHub 上的某一個(gè)開(kāi)源項(xiàng)目，那么不妨看看 GitHub Flow。

官方給的 GitHub Flow 流程如下：

它的流程是這樣的：

1. 需要開(kāi)發(fā)新功能或者修復(fù) BUG 的時(shí)候，從 master 上拉一個(gè)新的分支下來(lái)。
2. 新的分支開(kāi)發(fā)完成后，或者說(shuō)當(dāng)你遇到困難開(kāi)發(fā)不下去的時(shí)候，都可以發(fā)起一個(gè) pr（Pull Request）。
3. pr 既提交代碼，也讓其他同事 review 你的代碼，在這個(gè)過(guò)程中，你可以不斷提交 pr。
4. 最終你的 pr 被接受，合并進(jìn) master。

GitHub 工作流雖然用著很簡(jiǎn)單，但是他的問(wèn)題也很明顯，就是沒(méi)有對(duì)常見(jiàn)的工作場(chǎng)景中的問(wèn)題提出解決辦法。

3. GitLab Flow

GitLab Flow 結(jié)合了 Git Flow 與 GitHub Flow 的優(yōu)點(diǎn)，它不像 Git Flow 有那么多容易把新手繞暈的分支，同時(shí)它又可以適應(yīng)不同的開(kāi)發(fā)環(huán)境。

GitLab Flow 的最大原則叫做 upstream first，中文譯作“上游優(yōu)先”：即只存在一個(gè)主分支 master，它是所有其他分支的 upstream，只有上游分支采納的代碼變化，才能應(yīng)用到其他分支。

對(duì)于“持續(xù)發(fā)布”的項(xiàng)目，我們可以在 master 分支以外，再建立不同的環(huán)境分支。例如開(kāi)發(fā)的分支是 master，預(yù)發(fā)布的分支是 pre-production，生產(chǎn)環(huán)境的分支是 production。

在這里開(kāi)發(fā)分支是預(yù)發(fā)分支的 upstream，預(yù)發(fā)分支又是生產(chǎn)分支的 upstream。代碼的變化，必須由上游向下游發(fā)展。比如，生產(chǎn)環(huán)境出現(xiàn)了 bug，這時(shí)就要新建一個(gè)功能分支，先把它合并到 master，確認(rèn)沒(méi)有問(wèn)題，再 cherry-pick 到 pre-production，這一步也沒(méi)有問(wèn)題，才進(jìn)入 production，如下圖：

只有緊急情況，才允許跳過(guò)上游，直接合并到下游分支。

有穩(wěn)定的版本需要發(fā)布時(shí)，我們就從 master 上拉一個(gè)新的分支出來(lái)，作為發(fā)版時(shí)候的分支，這些分支上不要開(kāi)發(fā)新功能，只有修補(bǔ) BUG 的時(shí)候

對(duì)于”版本發(fā)布”的項(xiàng)目，建議的做法是每一個(gè)穩(wěn)定版本，都要從master分支拉出一個(gè)分支，比如2-3-stable、2-4-stable等等。

以后，只有修補(bǔ)bug，才允許將代碼合并到這些分支，并且此時(shí)要更新小版本號(hào)即可。

4. 小結(jié)

好啦這就是常見(jiàn)的三個(gè) Git 玩轉(zhuǎn)流程，其實(shí)我們自己開(kāi)發(fā)不必這么死板，結(jié)合自己的項(xiàng)目來(lái)就行了，松哥的項(xiàng)目，master、develop 以及 release 三個(gè)分支是固定的，這三個(gè)分支的作用跟前面介紹的 Git Flow 也是一致的，在此基礎(chǔ)之上，其他的基本上沒(méi)有太多限制，比較自由。

審核編輯：符乾江