團隊協作的三大工作流
Git 作為一個代碼版本管理系統，利用它強大的版本控制和branch，我們能做出一些優雅的團隊協作的工作流。
這也是之前我在Git文章談到的，Git對團隊協作具有很大幫助，這篇文章我将來談談基于Git的三大工作流。
工作流 在英語中叫做：
workflow
，從名字上看出團隊協作應該像流水一樣，順暢。
- 好的工作流能給你團隊合作帶來很大的好處，有條不紊的應對各種問題。
- 壞的工作流可能會使本來一個很好的項目失敗在團隊協作上。
是以我們來學學程式員常用到的工作流。
現在三種廣泛使用的工作流程：
- Git flow
- Github flow
- Gitlab flow
如果你對Git還不是很熟悉，可以先閱讀下面的文章。
- 用《隻狼》教你學會Git（上）
- 用《隻狼》教你學會Git（中）
- 用《隻狼》教你學會Git（下）
一、功能驅動
本文的三種工作流程，有一個共同點：都采用 “功能驅動式開發”（Feature-driven development，簡稱FDD）。
它指的是，需求是開發的起點，先有需求再有功能分支（feature branch）或者更新檔分支（hotfix branch）。完成開發後，該分支就合并到主分支，然後被删除。
二、Git flow
最早誕生、并得到廣泛采用的一種工作流程，就是Git flow，相對來說是複雜度較高的，可以看到下面這張圖檔：
2.1 特點
從上面這張圖檔可以看到，它最主要的特點有兩個。
首先，項目存在兩個長期分支。
- 主分支
master
- 開發分支
develop
- master用于存放對外釋出的版本，任何時候在這個分支拿到的，都是穩定的分布版；
- develop用于日常開發，存放最新的開發版。
其次，項目存在三種短期分支。
- 功能分支（feature branch）
- 更新檔分支（hotfix branch）
- 預發分支（release branch）
所謂短期分支就是，基于功能，更新檔，預釋出，一旦完成開發，它們就會被合并進
develop
或
master
，然後被删除。
2.2 優缺點
Git flow的優點是清晰可控，缺點是相對複雜，需要同時維護兩個長期分支。
大多數工具都将
master
當作預設分支，可是開發是在
develop
分支進行的，雖然讓邏輯更清晰，但這導緻經常要切換分支，有一定的複雜度。
但更大問題在于，這個模式是基于"版本釋出"的，目标是一段時間以後産出一個新版本。但是，很多網站項目是"持續釋出"，也就是說如果我釋出版本的頻率很高，代碼一有變動，就部署在
master
一次。這時，
master
分支和
develop
分支的差别不大，沒必要維護兩個長期分支。
是以根據具體項目情況，選擇合作方式。
三、Github flow
Github flow 是Git flow的簡化版，專門配合"持續釋出"。它是 Github.com 使用的工作流程，也同時是參加開源項目的主要合作方式之一。
3.1 流程
它隻有一個長期分支，就是
master
，是以用起來非常簡單。
定義：
- 合作的倉庫：我稱之主倉庫；
- 個人fork之後的倉庫：我稱之為子倉庫。
官方推薦的流程如下。
預處理：先從主倉庫fork出一個子倉庫。
第一步：根據需求，從子倉庫的
master
拉出新分支，不區分功能分支或更新檔分支。
第二步：新分支開發完成後，或者需要讨論的時候，就向中央倉庫的
master
發起一個pull request（簡稱PR）。
第三步：Pull Request既是一個通知，讓别人注意到你的請求，又是一種對話機制，大家一起評審和讨論你的代碼。對話過程中，你還可以不斷送出代碼。
第四步：你的Pull Request被接受，合并進
，重新部署後，原來你拉出來的那個分支就被删除。（先部署再合并也可。）master
3.2 評價
Github flow 的最大優點就是簡單，對于"持續釋出"的産品，可以說是最合适的流程。
問題在于它的假設：
master
分支的更新與産品的釋出是一緻的。也就是說，
master
分支的最新代碼，預設就是目前的線上代碼。
可是，有些時候并非如此，代碼合并進入
master
分支，并不代表它就能立刻釋出。比如，蘋果商店的APP送出稽核以後，等一段時間才能上架。
這時，如果還有新的代碼送出，
master
分支就會與剛釋出的版本不一緻。
另一個例子是，有些公司有釋出視窗，隻有指定時間才能釋出，這也會導緻線上版本落後于
master
分支。
上面這種情況，隻有
master
一個主分支就不夠用了。通常，你不得不在
master
分支以外，另外建立一個
production
分支跟蹤線上版本，即在等待中進行繼續開發。
不過上面所說的情況不是所有項目都能遇到的，根據實際情況随機應變很重要
四、Gitlab flow
Gitlab flow 是 Git flow 與 Github flow 的綜合。它吸取了兩者的優點，既有适應不同開發環境的彈性，又有單一主分支的簡單和便利。它是 Gitlab.com 推薦的做法。
4.1 上遊優先
Gitlab flow 的最大原則叫做"上遊優先"（upsteam first），即隻存在一個主分支
master
，它是所有其他分支的"上遊"。隻有上遊分支采納的代碼變化，才能應用到其他分支。
4.2 持續釋出
Gitlab flow 分成兩種情況，适應不同的開發流程。
對于"持續釋出"的項目，它建議在
master
分支以外，再建立不同的環境分支。比如，"開發環境"的分支是
master
，"預發環境"的分支是
pre-production
，"生産環境"的分支是
production
。
開發分支是預發分支的"上遊"，預發分支又是生産分支的"上遊"。代碼的變化，必須由"上遊"向"下遊"發展。比如，生産環境出現了bug，這時就要建立一個功能分支，先把它合并到
master
，确認沒有問題，再
cherry-pick
到
pre-production
，這一步也沒有問題，才進入
production
。
隻有緊急情況，才允許跳過上遊，直接合并到下遊分支。
4.3 版本釋出
對于"版本釋出"的項目，建議的做法是每一個穩定版本，都要從
master
分支拉出一個分支，比如
2-3-stable
、
2-4-stable
等等。
以後，隻有修補bug，才允許将代碼合并到這些分支，并且此時要更新小版本号。
總結：
對于三大工作流，我個人認為沒有絕對的最好和最壞的合作方式.
在不同場景下，不同工作流各自有着各自的優勢，根據團隊情況，項目情況選擇合适的工作流是最重要的。
同時可以根據實際對工作流進行修改，不必生搬硬套。
希望你有所收獲～