開篇

Git 三大特色，分支，暫存區，工作流，今天終於要寫到 WorkFlow 了，我彷佛已經看到勝利的曙光，走起。

何謂工作流

WorkFlow 的字面意思，工作流，即工作流程。在分支篇裏，有說過這樣的話：因爲有分支的存在，才構成了多工作流的特色。事實的確如此，因爲項目開發中，多人協作，分支很多，雖然各自在分支上互不干擾，但是我們總歸需要把分支合併到一起，而且真實項目中涉及到很多問題，例如版本迭代，版本發佈，bug 修復等，爲了更好的管理代碼，需要制定一個工作流程，這就是我們說的工作流，也有人叫它分支管理策略。

工作流不涉及任何命令，因爲它就是一個規則，完全由開發者自定義，並且自遵守，正所謂無規矩不成方圓，就是這個道理。

工作流最受歡迎榜

目前使用度最高的工作流前三名（排名不分先後哈）分別是以下三種：

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

Git 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 Flow 是大型程序員交友社區 GitHub 制定並使用的工作流模型，由 scott chacon 在 2011 年 8月 31 號正式發佈。

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

GitHub Flow 示意圖

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

GitHub Flow 模型簡單說明

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

特色之 Pull Request

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

可以很好控制分支合併權限。

分支不是你想合併就合併，需要對方同意吶
問題討論或者尋求其他小夥伴們的幫助。

和拉個討論組差不多，可以選擇相關的人蔘與，而且參與的人還可以向你的分支提交代碼，可以說，是非常適合代碼交流了。
代碼 Review 。

如果代碼寫的很爛，有了 pull request 提供的評論功能支持，準備好接受來自 review 的實時吐槽吧。當然你如果寫的很棒，肯定也能被雙擊666的。

特色之 issue tracking 問題追蹤

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

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

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

如果你想體驗 GitHub Flow

GitHub 社區使用的就是這個工作流模型，而且幫助文檔非常詳細，可以建個項目，多耍耍。

GitLab Flow

這個工作流十分地年輕，是 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 分支，遵循 “上游優先” 原則。

最後

這個博客，真的寫好久，因爲我之前對工作流的這個概念，也只限於 Git Flow ，寫博客的過程中，自己也學習到很多，我目前的工作項目中，使用的是 GitLab + Git Flow 這種混搭 Style，側面證明了 Git 的使用真的很靈活自由。但是我很喜歡 GitHub 的 Pull Request 和 GitLab 的 Merge Request，以後會多嘗試。

GitHub Flow 和 GitLab Flow 的介紹很多都是來源於各自的英文介紹文檔，不對之處，還請評論指證，下篇博客見。See you~

參考鏈接：

歡迎訂閱我的Git系列文章

歡迎關注博主的微信公衆號，快快加入哦，期待與你一起成長！

DRPrincess

發佈了125 篇原創文章 · 獲贊 367 · 訪問量 124萬+

他的留言板關注

Git三大特色之WorkFlow(工作流)

開篇