Git最佳實踐，什么才是最佳工作流

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

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

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

1. Git Flow

先來看 Git Flow。

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

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

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

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

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

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

feature branches

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

hotfixes branches

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

release branches

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

大概就是這個意思。

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

2. GitHub Flow

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

官方給的 GitHub Flow 流程如下：

它的流程是這樣的：

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

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

3. GitLab Flow

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

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

對于“持續(xù)發(fā)布”的項目，我們可以在 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，這時就要新建一個功能分支，先把它合并到 master，確認沒有問題，再 cherry-pick 到 pre-production，這一步也沒有問題，才進入 production，如下圖：

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

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

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

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

4. 小結(jié)

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

審核編輯：符乾江