Git 三大特色，分支，暫存區(qū)，工作流。工作流不涉及任何命令，通俗一點的稱呼就是分支策略。

何謂分支策略

Git的特色之一就是可以靈活的建立分支，因為有分支的存在，才構(gòu)成了多工作流的特色。事實的確如此，因為項目開發(fā)中，多人協(xié)作，分支很多，雖然各自在分支上互不干擾，但是我們總歸需要把分支合并到一起，而且真實項目中涉及到很多問題，例如版本迭代，版本發(fā)布，bug 修復(fù)等，為了更好的管理代碼，需要制定一個工作流程，這就是通常意義上的Workflow，也就是我們常說的分支管理策略。

熱度最高的分支管理策略

目前使用度最高的工作流前三名分別是以下三種(排名不分先后)：

• Git Flow
• GitHub Flow
• GitLab Flow

其中 Git Flow 出現(xiàn)的最早，GitHub Flow 在 Git Flow 的基礎(chǔ)上，做了一些優(yōu)化，適用于持續(xù)版本的發(fā)布，而 GitLab Flow 出現(xiàn)的時間比較晚，所以綜合前面兩種工作流的優(yōu)點，制定而成的一個工作流。

Git Flow

Git Flow是 Vincent Driessen 2010 年發(fā)布出來的他自己的分支管理模型，屬于強(qiáng)流程性，使用度非常高，比較適合開發(fā)技術(shù)能力中等的團(tuán)隊作戰(zhàn)。

Git Flow 的分支結(jié)構(gòu)很特別，按功能來說，可以分支為5種分支，從5 種分支的生命時間上，又可以分別歸類為長期分支和暫時分支，或者更貼切描述為，主要分支和協(xié)助分支。

主要分支：

在采用 Git Flow 工作流的項目中，代碼的中央倉庫會一直存在以下兩個長期分支：

• master
• develop

其中 origin/master 分支上的最新代碼永遠(yuǎn)是版本發(fā)布狀態(tài)。origin／develop 分支則是最新的開發(fā)進(jìn)度。

當(dāng) develop 上的代碼達(dá)到一個穩(wěn)定的狀態(tài)，可以發(fā)布版本的時候，develop上這些修改會以某種特別方式被合并到 master 分支上，然后標(biāo)記上對應(yīng)的版本標(biāo)簽。

協(xié)助分支：

除了主要分支，Git Flow 的開發(fā)模式還需要一系列的協(xié)助分支，來幫助更好的功能的并行開發(fā)，簡化功能開發(fā)和問題修復(fù)。
協(xié)助分支分為以下幾類：

• Feature Branch
• Release Branch
• Hotfix Branch

Feature 分支用來做分模塊功能開發(fā)，建議命名為feature-xxx,模塊完成之后，會合并到 develop 分支，然后刪除。

Release 分支用來做版本發(fā)布的預(yù)發(fā)布分支，建議命名為 release-xxx。例如在軟件 1.0.0 版本的功能全部開發(fā)完成，提交測試之后，從 develop 檢出release-1.0.0 ,測試中出現(xiàn)的小問題，在 release 分支進(jìn)行修改提交，測試完畢準(zhǔn)備發(fā)布的時候，代碼會合并到 master 和 develop，master 分支合并后會打上對應(yīng)版本標(biāo)簽 v1.0.0, 合并后刪除自己，這樣做的好處是，在測試的時候，不影響下一個版本功能并行開發(fā)。

Hotfix 分支是用來做線上的緊急 bug 修復(fù)的分支,建議命名為 hotfix-xxx。當(dāng)線上某個版本出現(xiàn)了問題，將檢出對應(yīng)版本的代碼，創(chuàng)建 Hotfix 分支，問題修復(fù)后，合并回 master 和 develop ，然后刪除自己。這里注意，合并到 master 的時候，也要打上修復(fù)后的版本標(biāo)簽。

Git Flow Branching Model.png

圖中畫了 Git Flow 的五種分支，master，develop，feature ,release , hoxfixes，其中 master 和 develop 字體被加粗代表主要分支。master 分支每合并一個分支，無論是 hotfix 還是 release ,都會打一個版本標(biāo)簽。通過箭頭可以清楚的看到分支的開始和結(jié)束走向，例如 feature 分支從 develop 開始，最終合并回 develop ，hoxfixes 從 master 檢出創(chuàng)建，最后合并回 develop 和 master，master 也打上了標(biāo)簽。

GitHub Flow

GitHub Flow 是大型程序員交友社區(qū) GitHub 制定并使用的工作流模型，由 scott chacon 在 2011 年 8月 31 號正式發(fā)布。因為 Git Flow 對于大部分開發(fā)人員和團(tuán)隊來說，稍微有些復(fù)雜，而且沒有 GUI 圖形頁面，只能命令行操作，所以為了更好的解決這些問題，GitHub Flow 應(yīng)運(yùn)而生了。

GitHub Flow.png

對比上面那張 Git flow 分支模型圖，GitHub flow真的可以稱得上簡單明了，因為 GitHub Flow 推薦做法是只有一個主分支 master，團(tuán)隊成員們的分支代碼通過 pull Request 來合并到 master 上。這種分支策略適合團(tuán)隊開發(fā)技術(shù)比較高的團(tuán)隊使用，否則就是no zuo no die。

GitHub Flow 模型簡單說明

1. 只有一個長期分支 master ,而且 master 分支上的代碼，永遠(yuǎn)是可發(fā)布狀態(tài),一般 master 會設(shè)置 protected 分支保護(hù)，只有有權(quán)限的人才能推送代碼到 master 分支。
2. 如果有新功能開發(fā)，可以從 master 分支上檢出新分支。
3. 在本地分支提交代碼，并且保證按時向遠(yuǎn)程倉庫推送。
4. 當(dāng)你需要反饋或者幫助，或者你想合并分支時，可以發(fā)起一個 pull request。
5. 當(dāng) review 或者討論通過后，代碼會合并到目標(biāo)分支。
6. 一旦合并到 master 分支，應(yīng)該立即發(fā)布。

其中最有特色的就是pull request，后來GitLab Flow也受此啟發(fā)有了Merge Request。

GitLab Flow

GitLab Flow是 GitLab 的 CEO Sytse Sijbrandij 在 2014 年 9月 29 正式發(fā)布出來的。因為出現(xiàn)的比前面兩種工作流稍微晚一些，所以它有個非常大的優(yōu)勢，集百家之長，補(bǔ)百家之短。

GitLab 既支持 Git Flow 的分支策略，也有 GitHub Flow 的 Pull Request（ Merge Request ） 和 issue tracking。

針對GitHub里面只有一個Master分支的情況，從需要發(fā)布的環(huán)境的角度出發(fā)，添加了 pre-production 和 prodution 分支都對應(yīng)不同的環(huán)境，這個分支策略比較適用服務(wù)端，測試環(huán)境，預(yù)發(fā)環(huán)境，正式環(huán)境，一個環(huán)境建一個分支。

environment_branches.png

這里要注意，代碼合并的順序，要按環(huán)境依次推送，確保代碼被充分測試過,才會從上游分支合并到下游分支。除非是很緊急的情況，才允許跳過上游分支，直接合并到下游分支。這種規(guī)則稱之為 “upstream first”，也就是 “上游優(yōu)先”。

在 Git Flow ,版本記錄是通過 master 上的 tag 來記錄。發(fā)現(xiàn)問題，創(chuàng)建 hotfix 分支，完成之后合并到 master 和 develop。

在 GitLab Flow ，建議的做法是每一個穩(wěn)定版本，都要從master分支拉出一個分支，比如2-3-stable、2-4-stable等等。發(fā)現(xiàn)問題，就從對應(yīng)版本分支創(chuàng)建修復(fù)分支，完成之后，先合并到 master，才能再合并到 release 分支，遵循 “上游優(yōu)先” 原則。

release_branches.png

GitLab中的Merge Request（MR，合并請求）是作為編碼協(xié)作及版本控制平臺的 GitLab 的基礎(chǔ)功能。就和它的命名一樣：是一個將一個分支合并到另一個分支上的請求。
通過 GitLab 的 Merge requests，我們可以：

• 對比兩個分支的差異
• 逐行地去 Review 和討論改動內(nèi)容
• 將 MR 指派給任何已注冊用戶，并且可以任意多地改變受理人
• 通過 UI 界面去解決沖突

以上三種是常見模式，補(bǔ)充一個目前比較高大上，但很少團(tuán)隊可以達(dá)到的模式，主干開發(fā)。

主干開發(fā)

主線開發(fā)模型:如下圖所示，主線開發(fā)模型是同一個產(chǎn)品的所有的開發(fā)人員共享一個 trunk，開發(fā)人員可以有自己的私有分支，但所有修改最后都會回到主干，只有在 Release 時才會創(chuàng)建 Release Branch，由 Release Engineer 進(jìn)行維護(hù)，發(fā)布分支是主干某個時點的快照，必要時通過 cherry-pick 從主干挑揀代碼到發(fā)布分支?；谥鞲傻拈_發(fā)的優(yōu)點是保證了所有用戶看到的都是同一份代碼的最新版本，避免了合并分支時的麻煩，缺點是不適于瀑布開發(fā)模型，同時對開發(fā)人員和發(fā)布分支的維護(hù)人員的技術(shù)要求比較高。

image

圖2 主線開發(fā)模型

CC先生說:
可以看到Git的分支策略是非常靈活的工作流方式，各個開發(fā)團(tuán)隊可以根據(jù)自己的團(tuán)隊需求來定制自己的分支策略，沒有最好只有最適合。每一種分支策略其實就是一個開發(fā)模式價值觀的顯性體現(xiàn)。

后面會專門用一篇文章來整理如何使用GitLab中的Merge Request來實現(xiàn)Code Review的功能。