WorkFlow 的字面意思，工作流，即工作流程。正因為Git有分支的存在，才構成了多工作流的特色。因為項目開發中，多人協作，分支很多，雖然各自在分支上互不幹擾，但是我們總歸需要把分支合并到一起，而且真實項目中涉及到很多問題，例如版本叠代，版本發布，bug 修複等，為了更好的管理代碼，需要制定一個工作流程，這就是我們說的工作流，也有人叫它分支管理策略。工作流不涉及任何命令，因為它就是一個規則，完全由開發者自定義并自遵守。

目前使用度最高的工作流前三名分别是以下三種：

• Git Flow
• GitHub Flow
• GitLab Flow

其中 Git Flow 出現的最早，GitHub Flow 在 Git Flow 的基礎上，做了一些優化，适用于持續版本的發布，而 GitLab Flow 出現的時間比較晚，所以綜合前面兩種工作流的優點，制定而成的一個工作流。

這個工作流，是 Vincent Driessen 2010 年發布出來的他自己的分支管理模型，到現在為止，使用度非常高。

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

主要分支：

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

• master
• develop

其中 origin/master 分支上的最新代碼永遠是版本發布狀态。origin／develop 分支則是最新的開發進度。

當 develop 上的代碼達到一個穩定的狀态，可以發布版本的時候，develop上這些修改會以某種特别方式被合并到 master 分支上，然後标記上對應的版本标簽。

協助分支：

除了主要分支，Git Flow 的開發模式還需要一系列的協助分支，來幫助更好的功能的并行開發，簡化功能開發和問題修複。是的，就是下面的三類分支。這類分支是暫時分支非常無私奉獻，在需要它們的時候，迫切地創建，用完它們的時候，又揮揮衣袖地徹底消失。
協助分支分為以下幾類：

• Feature Branch
• Release Branch
• Hotfix Branch

Feature 分支用來做分模塊功能開發，命名看開發者喜好，不要和其他類型的分支命名弄混淆就好，舉個例子，命名為 master 就是一個非常不妥當的舉動。模塊完成之後，會合并到 develop 分支，然後删除自己。

Release 分支用來做版本發布的預發布分支，建議命名為 release-xxx。例如在軟件 1.0.0 版本的功能全部開發完成，提交測試之後，從 develop 檢出release-1.0.0 ,測試中出現的小問題，在 release 分支進行修改提交，測試完畢準備發布的時候，代碼會合并到 master 和 develop，master 分支合并後會打上對應版本标簽 v1.0.0, 合并後删除自己，這樣做的好處是，在測試的時候，不影響下一個版本功能并行開發。

Hotfix 分支是用來做線上的緊急 bug 修複的分支,建議命名為 hotfix-xxx。當線上某個版本出現了問題，将檢出對應版本的代碼，創建 Hotfix 分支，問題修複後，合并回 master 和 develop ，然後删除自己。這裡注意，合并到 master 的時候，也要打上修複後的版本标簽。

Merge 加上 no-ff 參數

需要說明的是，Git Flow 的作者 Vincent Driessen 非常建議，合并分支的時候，加上 no-ff 參數，這個參數的意思是不要選擇 Fast-Forward 合并方式，而是策略合并，策略合并會讓我們多一個合并提交。這樣做的好處是保證一個非常清晰的提交曆史，可以看到被合并分支的存在。

下面是對比圖，左側是加上參數的，後者是普通的提交：

Git Flow 示意圖

在剛學習 Git 的時候，看到很多次這個圖，一直都沒看懂過，也不知道這張圖來自 Git Flow ，隻能說，我當初學 Git 的方式的确不怎麼正确 。下面來分析一下。

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

GitHub Flow 是大型程序員交友社區 GitHub 制定并使用的工作流模型，由 scott chacon 在 2011 年 8月 31 号正式發布。

文章中說，因為 Git Flow 對于大部分開發人員和團隊來說，稍微有些複雜，而且沒有 GUI 圖形頁面，隻能命令行操作，所以為了更好的解決這些問題，GitHub Flow 應運而生了。

GitHub Flow 示意圖

對比上面那張 Git flow 分支模型圖，真的可以稱得上簡單明了啦，因為 GitHub Flow 推薦做法是隻有一個主分支 master，團隊成員們的分支代碼通過 pull Request 來合并到 master 上。

github flow 示意圖

GitHub Flow 模型簡單說明

1. 隻有一個長期分支 master ,而且 master 分支上的代碼，永遠是可發布狀态,一般 master 會設置 protected 分支保護，隻有有權限的人才能推送代碼到 master 分支。
2. 如果有新功能開發，可以從 master 分支上檢出新分支。
3. 在本地分支提交代碼，并且保證按時向遠程倉庫推送。
4. 當你需要反饋或者幫助，或者你想合并分支時，可以發起一個 pull request。
5. 當 review 或者讨論通過後，代碼會合并到目标分支。
6. 一旦合并到 master 分支，應該立即發布。

特色之 Pull Request

在我看來，GitHub Flow 最大的特色就是 Pull Request 的提出，這是一個偉大的發明，它的用處并不僅僅是合并分支，還有以下功能：

• 可以很好控制分支合并權限。 分支不是你想合并就合并，需要對方同意
• 問題讨論 或者 尋求其他小夥伴們的幫助。 和拉個讨論組差不多，可以選擇相關的人參與，而且參與的人還可以向你的分支提交代碼，可以說，是非常适合代碼交流了。
• 代碼 Review 。 如果代碼寫的很爛，有了 pull request 提供的評論功能支持，準備好接受來自 review 的實時吐槽吧。當然你如果寫的很棒，肯定也會得到認可。

特色之 issue tracking 問題追蹤

日常開發中，會用到很多第三方庫，然後使用過程中，出現了問題，是不是第一個反應是去這個第三方庫的 GitHub 倉庫去搜索一下 issue ，看沒有人遇到過，項目維護者修複了沒有，一般未解決的 issue 是 open 狀态，已解決的會被标記為 closed。這就是 issue tracking。

如果你是一個項目維護者，除了标記 issue 的開啟和關閉，還可以給它标記上不同的标簽，來優化項目。當提交的時候，如果提交信息中有 fix #1 等字段，可以自動關閉對應編号的 issue。

issue 标簽

issue tracking 真的是非常适合開源項目。

如果你想體驗 GitHub Flow

GitHub 社區使用的就是這個工作流模型，而且幫助文檔非常詳細。

這個工作流十分地年輕，是 GitLab 的 CEO Sytse Sijbrandij 在 2014 年 9月 29 正式發布出來的。因為出現的比前面兩種工作流稍微晚一些，所以它有個非常大的優勢，集百家之長，補百家之短。

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

Git Flow & GitHub Flow 的瑕疵

當 Git Flow 出現後，它解決了之前項目管理中很讓人頭疼的分支管理問題，但是實際使用過程中，也暴露了很多問題：

• 默認工作分支是 develop，但是大部分版本管理工具默認分支都是 master，開始的時候總是需要切換很麻煩。
• Hotfix 和 Release 分支在需要版本快速叠代的項目中，幾乎用不到，因為剛開發完就直接合并到 master 發版，出現問題 develop 就直接修複發布下個版本了。
• Hotfix 和 Release 分支，一個從 master 創建，一個從 develop 創建，使用完畢，需要合并回 develop 和 master。而且在實際項目管理中，很多開發者會忘記合并回 develop 或者 master。

GitHub Flow 的出現，非常大程度上簡化了 Git Flow ，因為隻有一個長期分支 master，并且提供 GUI 操作工具，一定程度上避免了上述的幾個問題，然而在一些實際問題面前，僅僅使用 master 分支顯然有點力不從心，例如：

• 版本的延遲發布（例如 iOS 應用審核到通過中間，可能也要在 master 上推送代碼）
• 不同環境的部署 （例如：測試環境，預發環境，正式環境）
• 不同版本發布與修複 （是的，隻有一個 master 分支真的不夠用）

GitLab Flow 解決方案

為了解決上面那些毛茸茸的小問題，GitLab Flow 給出了以下的解決方法。

版本的延遲發布--Prodution Branch

master 分支不夠，于是添加了一個 prodution 分支，專門用來發布版本。

産品發布分支

不同環境的部署--Environment Branches & Upstream First

每個環境，都對應一個分支，例如下圖中的 pre-production 和 prodution 分支都對應不同的環境，我覺得這個工作流模型比較适用服務端，測試環境，預發環境，正式環境，一個環境建一個分支。

這裡要注意，代碼合并的順序，要按環境依次推送，确保代碼被充分測試過,才會從上遊分支合并到下遊分支。除非是很緊急的情況，才允許跳過上遊分支，直接合并到下遊分支。這個被定義為一個規則，名字叫 “upstream first”，翻譯過來是 “上遊優先”。

部署環境分支

版本發布分支--Release Branches & Upstream First

隻有當對外發布軟件的時候，才需要創建 release 分支。作為一個移動端開發來說，對外發布版本的記錄是非常重要的，如果線上出現了一個問題，需要拿到問題出現對應版本的代碼，才能準确定位問題。

在 Git Flow ,版本記錄是通過 master 上的 tag 來記錄。發現問題，創建 hotfix 分支，完成之後合并到 master 和 develop。

在 GitLab Flow ，建議的做法是每一個穩定版本，都要從master分支拉出一個分支，比如2-3-stable、2-4-stable等等。發現問題，就從對應版本分支創建修複分支，完成之後，先合并到 master，才能再合并到 release 分支，遵循 “上遊優先” 原則。

版本發布分支

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!