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

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

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

1. Git Flow

先來看 Git Flow。

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

在 Git Flow 中，有兩個長期存在且不會被刪除的分支：master 和 develop。

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

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

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

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

feature branches

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

hotfixes branches

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

release branches

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

大概就是這個意思。

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

2. GitHub Flow

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

官方給的 GitHub Flow 流程如下：

它的流程是這樣的：

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

GitHub 工作流雖然用著很簡單，但是他的問題也很明顯，就是沒有對常見的工作場景中的問題提出解決辦法。

3. GitLab Flow

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

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

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

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

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

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

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

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

4. 小結(jié)

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

審核編輯：符乾江