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