簡介
現(xiàn)代軟件開發(fā)過程中要實現(xiàn)高效的團隊協(xié)作，需要使用代碼分支管理工具實現(xiàn)代碼的共享、追溯、回滾及維護等功能。目前流行的代碼管理工具，包括CVS，SVN，Git，Mercurial等。相比CVS和SVN的集中管理，Git具有非常明顯的優(yōu)勢，例如：去中心化的代碼管理方式減少了開發(fā)者對中心服務器的依賴，每個成員在本地都有一個完整的代碼庫，在不聯(lián)網(wǎng)的情況下也能提交代碼；不同于SVN中的每個分支具有獨立的代碼，Git中的每一個分支只是指向當前版本的一個指針，Git的分支策略使創(chuàng)建和合并分支變得快捷靈活。
根據(jù)開源社區(qū)網(wǎng)站OpenHub的統(tǒng)計，使用Git管理代碼的項目逐年快速增加，如今Git在代碼管理領域已經(jīng)占據(jù)主導地位。??
在使用Git管理代碼以及多人協(xié)作的開發(fā)模式下，一個團隊甚至一個公司對Git的使用有統(tǒng)一規(guī)范的工作流程尤為重要，開發(fā)團隊遵循統(tǒng)一的規(guī)則執(zhí)行功能開發(fā)，問題修復，分支合并，版本迭代及發(fā)布等操作，可以使團隊合作變得平滑順暢，項目有序向前推進，我們把組織內(nèi)這樣的工作流程（workflow）稱為Git代碼分支管理模型，本文將介紹幾個主流的git代碼分支管理模型：
- Git flow
- GitHub flow
- GitLab flow
- TBD flow
Git flow
Git flow是由Vincent Driessen于2010 年提出的代碼分支管理模型，但是不要被名字欺騙了，git-flow并不是Git社區(qū)官方推薦的工作流。
Git flow存在兩個長期的獨立分支：主分支master和開發(fā)分支develop，主分支用于版本發(fā)布，主分支的每個版本都是質(zhì)量穩(wěn)定和功能齊全的發(fā)布版。開發(fā)分支用于日常開發(fā)工作，存放最新的開發(fā)版代碼。當開發(fā)分支的代碼達到穩(wěn)定狀態(tài)并可以發(fā)布版本時，代碼需要被合并到 master 分支，然后標記上對應的版本標簽（tag）。
如果需要開發(fā)新的功能或者解決代碼中的問題，則創(chuàng)建輔助分支來解決問題，輔助分支常用于：功能開發(fā)（Feature），版本發(fā)布（Release），問題修復（Hotfix）等，在輔助分支上的工作完成后，輔助分支將被刪除。
Feature分支的目的是開發(fā)新模塊或新功能以滿足客戶需求，從develop分支創(chuàng)建，開發(fā)結(jié)束后只需要合并回develop分支，并不需要合并回master主分支。
Release分支是用于準備發(fā)布的版本分支，從develop分支創(chuàng)建，創(chuàng)建時已經(jīng)包含了發(fā)布所需要的所有功能，所以在這個分支上不再開發(fā)新功能，僅對這個預發(fā)布版本進行修復問題，創(chuàng)建文檔及其他與發(fā)布相關的工作，一切就緒后將Release分支合并回master主分支并打上相應的版本號標簽（Tag），同時也合并回develop分支。創(chuàng)建單獨的Release分支可以避免在不同發(fā)布版本上的工作互相受影響，例如團隊A準備發(fā)布版本1.0的同時，團隊B正在進行版本1.1的功能開發(fā)，二者相互獨立，不會互相影響。
-
Hotfix分支通常用于緊急修復當前發(fā)布的版本中出現(xiàn)的嚴重問題，從發(fā)布版本的標簽或master主分支創(chuàng)建，問題修復后合并回master主分支并打上新的版本號標簽（Tag），同時也合并回develop分支或者正在進行中的Release分支。創(chuàng)建單獨的Hotfix分支可以避免打斷正在進行中的各項開發(fā)工作，客戶也不需要等到下一個發(fā)布周期才能拿到修復。
??
Git flow需要同時維護兩個甚至更多分支，Hotfix分支從master創(chuàng)建，Release和Feature分支從develop創(chuàng)建，工作完成后又需要將代碼合并回 develop 和 master。在實際應用中，很多開發(fā)者會忘記合并回 develop 或者 master，并且各輔助分支之間互相獨立，如果從master上pull代碼不夠及時，一方面可能造成某個分支長期使用已經(jīng)過時或者錯誤的代碼，另一方面如果與master相隔較遠，合并分支時可能會有大量代碼沖突，往往需要花費很多時間來消除代碼沖突，并且非常容易出錯，影響項目的持續(xù)集成。
Git flow的優(yōu)點在于流程清晰，分支管理嚴格，適用于發(fā)布周期比較長的“版本發(fā)布”，發(fā)布周期可能是幾周，幾個月，甚至更長時間。由于保持兩個長期分支同步的開銷較大，所以Git flow并不適用于快速的“持續(xù)發(fā)布”，ThoughtWorks還專門將Git flow列為不被推薦的技術，建議徹底停止使用。
GitHub flow
GitHub flow是由Scott Chacon于2011年提出的代碼分支管理模型，這是GitHub官方推薦的開發(fā)流程，以快速部署為目標，目前大部分開源項目都遵循這一流程。
Github flow最大的特點是只有一個長期分支，即主分支master，且主分支始終保持可發(fā)布狀態(tài)。從master上創(chuàng)建新分支進行功能開發(fā)、問題修復等，這些分支通過pull request將代碼合并到master。為了保證主分支的代碼質(zhì)量，master的權(quán)限只開放給一部分人。Pull request是請求別人pull你的代碼庫（repository），也就是把開發(fā)分支的代碼經(jīng)過代碼評審并通過測試后，讓有權(quán)限的管理員合并回master。不過在實際情況中，代碼評審不可能檢查出提交的代碼中的所有問題，所以對于每次提交的代碼進行自動化測試，主分支代碼的自動化部署尤其重要，自動化測試能在產(chǎn)品部署前及時發(fā)現(xiàn)一部分問題，如果產(chǎn)品部署之后發(fā)現(xiàn)嚴重問題，自動化部署可以在最短時間內(nèi)把產(chǎn)品回滾到上一個版本。
??
Github flow的優(yōu)點在于流程簡單靈活，不需要考慮及管理太多的分支，適用于需要快速集成及“持續(xù)發(fā)布”的項目，這類項目可能需要每天發(fā)布一個版本，甚至一天發(fā)布多個版本。但是對于應用場景比較復雜的情況，例如：多個環(huán)境下的產(chǎn)品部署，多個版本的發(fā)布或問題修復，只有一個master便會顯得力不從心。
GitLab flow
GitLab flow是由GitLab 的 CEO Sytse Sijbrandij 于 2014 年正式發(fā)布的代碼分支管理模型，屬于GitHub flow的演進版本，與GitHub相同之處是也存在一個長期主分支mater，從master上創(chuàng)建新分支進行功能開發(fā)、問題修復等，結(jié)束后合并回master。與GitHub不同之處是GitLab flow又考慮多環(huán)境部署等現(xiàn)實因素，增加production產(chǎn)品分支用于在不同的環(huán)境下部署產(chǎn)品，或者從master的穩(wěn)定版本創(chuàng)建release發(fā)布分支用于發(fā)布軟件。
如果在產(chǎn)品分支或者發(fā)布分支發(fā)現(xiàn)問題，就從對應版本分支創(chuàng)建修復分支，修復完成之后，GitLab flow遵循 “上游優(yōu)先” 的合并策略，也就是將代碼先合并到 master，再合并到下游的production或release分支。
和Github flow類似，master的修改權(quán)限只開放給部分人，開發(fā)分支的工作完成后，代碼通過merge request（類似于GitHub flow中的pull request）請求有權(quán)限的管理員把代碼合并（merge）回主分支。
TBD flow
TBD (Trunk-based Development) flow是由Paul Hammant于2013年提出的模型, TBD flow最大的特點是所有開發(fā)都基于主干trunk，不再有長期的開發(fā)分支，要求所有的提交盡快回到主干，這樣可以共享最新的代碼，并且能盡可能地減少合并沖突。如果需要發(fā)布版本，可以基于trunk直接生成新的分支用于發(fā)布。
TBD flow沒有pull或者push request，要求開發(fā)人員盡快把代碼提交到主干分支，但是TBD flow缺乏嚴格的流程來保證每一份提交代碼的質(zhì)量，如果一些項目開發(fā)人員眾多且水平不一，同時工作在主分支上可能會在產(chǎn)品發(fā)布時才發(fā)現(xiàn)不可預知的問題，所以TBD flow更適用于需要快速迭代的產(chǎn)品，如果在主干分支上發(fā)現(xiàn)問題，可以快速進行修復再合并回主干分支。
??
TBD++ flow
TBD++ flow是Arrus公司軟件研發(fā)部門從2015年開始一直沿用的Git分支管理模型，產(chǎn)品項目的客戶主要是電信級服務運營商，每個國家或地區(qū)的需求在主要功能上一致，但在客戶定制化方面又存在不少差異，同時項目開發(fā)周期較長，整個周期一般在3個月到2年之間，軟件產(chǎn)品在項目前期需要有快速的迭代，在項目后期需要有穩(wěn)定的發(fā)布版本。TBD++ flow以敏捷開發(fā)為核心，同時吸收了以上幾個主流模型的優(yōu)點，主要特點如下：
1. 基于功能的主分支
只存在一個長期的獨立分支，即主分支master，主分支上功能齊全，通過自動測試保證基本功能運行正常，因為自動測試覆蓋不全面或者手動測試不及時，所以無法保證主分支的每個版本都是質(zhì)量穩(wěn)定的發(fā)布版，但是可以根據(jù)功能的完成程度直接從主分支上創(chuàng)建迭代版本用于針對不同客戶或者不同時期的功能演示?；趍aster開發(fā)功能或者修復問題需要用到以下兩個輔助分支：
Feature分支：為了開發(fā)新模塊或新功能以滿足客戶需求，從主分支上創(chuàng)建Feature分支，但是并不要求Feature分支上所有的提交盡快回到主分支，開發(fā)完成并且通過代碼評審及功能測試后才能合并回master主分支。為了共用主分支上的最新代碼以及避免合并代碼時解決代碼沖突引起的額外開銷，在功能開發(fā)過程中Feature分支需要始終與master保持同步。
Bugfix分支：基于主分支創(chuàng)建Bugfix分支修復主分支上發(fā)現(xiàn)的問題，修復完成并且通過代碼評審后代碼合并回master主分支。
基于主分支的Feature分支和Bugfix分支完成后，開發(fā)者直接將代碼合并回主分支master，不需要像GitLab或GitHub那樣依賴于少數(shù)幾個有權(quán)限的管理員，這是因為如果一個項目中開發(fā)人員比較多的話，管理員沒辦法做到對每部分代碼都熟悉或掌握，所以代碼質(zhì)量交由代碼評審和功能測試來掌控，合并代碼回主分支的操作由開發(fā)者自己完成。
主分支上的新代碼有時候可能因為評審或測試不全面而帶來新問題，例如破壞其他功能模塊，甚至影響整體功能。為了能盡早發(fā)現(xiàn)問題，主分支上的每次提交都會觸發(fā)系統(tǒng)級自動化測試，并且周期性地對主分支進行人工測試。一旦發(fā)現(xiàn)問題，主分支的專職配置管理員（Software Configuration Manager，SCM）將根據(jù)問題的嚴重性和緊迫性決定是否需要直接回退引起問題的提交，或者基于master創(chuàng)建bugfix分支進行問題修復。
2. 基于發(fā)布的Release分支
Release分支負責對外發(fā)布軟件產(chǎn)品，每個Release分支也會配備專職版本配置管理員SCM，SCM具有對Release分支的最高管理權(quán)限。當master上已經(jīng)包含了某個發(fā)布所需要的所有功能，并且沒有已知的嚴重問題，此時由SCM從主分支上創(chuàng)建Release分支準備系統(tǒng)集成測試，和Git flow相同，在此分支上不再進行新功能的開發(fā)，僅在這個分支上進行修復問題，創(chuàng)建文檔，客戶參數(shù)配置及其他與發(fā)布相關的工作，這些代碼同時也需要合并回master以確保主分支功能的完整性。
在每個Release分支正式發(fā)布前可能還需要將主分支上的一部分關鍵問題的修復選擇性地同步（Cherry-pick）到Release分支，這個操作也是由SCM完成。
Release分支上的工作一切就緒并通過系統(tǒng)集成測試后，SCM在Release分支上打上相應的版本號標簽（Tag）進行發(fā)布，這點和Git flow在主分支上進行發(fā)布不同。
軟件產(chǎn)品發(fā)布之后，如果發(fā)現(xiàn)緊急或者嚴重的問題，此時需要基于版本發(fā)布時的Release分支標簽創(chuàng)建Hotfix分支來修復此類問題，問題修復后合并回該Release分支以及其他同樣需要此修復的Release分支，并打上新的版本號標簽（Tag）用于發(fā)布，同時代碼也需要合并回master以確保主分支的健壯性。
小結(jié)
以上幾個主流的git代碼分支管理模型各具特點，流程只是一個輔助工具，沒有最好，只有最合適，例如，如果開發(fā)團隊規(guī)模較小又比較分散，產(chǎn)品發(fā)布周期較短，可以選擇GitHub flow或者GitLab flow；如果開發(fā)團隊規(guī)模較大，產(chǎn)品發(fā)布周期較長可以選擇Git flow，發(fā)布周期較短可以選擇TBD flow；如果開發(fā)團隊規(guī)模大，產(chǎn)品發(fā)布周期長，同時對敏捷的要求比較高，可以考慮TBD++ flow。每個組織根據(jù)產(chǎn)品、項目、人員的特點找到最合適的模型才是我們共同的目標。
