簡介
現(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ā)結束后只需要合并回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的權限只開放給一部分人。Pull request是請求別人pull你的代碼庫（repository）喻括，也就是把開發(fā)分支的代碼經(jīng)過代碼評審并通過測試后邀杏，讓有權限的管理員合并回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ā)界逛、問題修復等，結束后合并回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的修改權限只開放給部分人，開發(fā)分支的工作完成后扰付，代碼通過merge request（類似于GitHub flow中的pull request）請求有權限的管理員把代碼合并（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)建迭代版本用于針對不同客戶或者不同時期的功能演示〕λ洌基于master開發(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ù)幾個有權限的管理員，這是因為如果一個項目中開發(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分支的最高管理權限着茸。當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以確保主分支的健壯性廊谓。
小結
以上幾個主流的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)品推姻、項目、人員的特點找到最合適的模型才是我們共同的目標框沟。
