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