GIT工作流-WorkFlow

阿新 • • 發佈：2018-11-15

開篇

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 示意圖

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 標籤

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~