Git - 【轉】Git分支模型

原文鏈接：https://www.jianshu.com/p/fc3b3bce5d8a
本文是對原文內容的摘取和擴展

1 - Git的優勢

Git 可以在本地進行提交以支持離線工作；
Git 可以在本地創建分支並且沒有命名空間衝突的問題；
Git 可以讓提交通過 Pull Request 的方式進行，不需要所有的開發者都有主倉庫的寫權限；
Git 在優化性能時選擇了合併分支作爲主要的性能衡量指標，將合併分支變成了成本非常低的操作以鼓勵分支的使用；
Git 通過 SHA-1 哈希來保證倉庫中數據的可靠性，通過 SHA-1 就可以對數據進行校驗，抵禦了來自攻擊者的惡意篡改；

2 - Git分支模型

在使用Git管理代碼以及多人協作的開發模式下，一個團隊甚至一個公司對Git的使用有統一規範的工作流程尤爲重要
開發團隊遵循統一的規則執行功能開發，問題修復，分支合併，版本迭代及發佈等操作，可以使團隊合作變得平滑順暢，項目有序向前推進，我們把組織內這樣的工作流程（workflow）稱爲Git代碼分支管理模型
主流的git代碼分支管理模型：

• Git flow
• GitHub flow
• GitLab flow
• TBD flow

2.1 Git flow

Git flow是由Vincent Driessen於2010 年提出的代碼分支管理模型。

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列爲不被推薦的技術，建議徹底停止使用。

2.2 GitHub flow

GitHub flow是由Scott Chacon於2011年提出的代碼分支管理模型，這是GitHub官方推薦的開發流程，以快速部署爲目標，目前大部分開源項目都遵循這一流程。

Github flow最大的特點是隻有一個長期分支，即主分支master，且主分支始終保持可發佈狀態。
從master上創建新分支進行功能開發、問題修復等，這些分支通過pull request將代碼合併到master。
爲了保證主分支的代碼質量，master的權限只開放給一部分人。

Pull request是請求別人pull你的代碼庫（repository），也就是把開發分支的代碼經過代碼評審並通過測試後，讓有權限的管理員合併回master。
不過在實際情況中，代碼評審不可能檢查出提交的代碼中的所有問題，所以對於每次提交的代碼進行自動化測試，
主分支代碼的自動化部署尤其重要，自動化測試能在產品部署前及時發現一部分問題，如果產品部署之後發現嚴重問題，自動化部署可以在最短時間內把產品回滾到上一個版本。

Github flow的優點在於流程簡單靈活，不需要考慮及管理太多的分支，適用於需要快速集成及“持續發佈”的項目，這類項目可能需要每天發佈一個版本，甚至一天發佈多個版本。
但是對於應用場景比較複雜的情況，例如：多個環境下的產品部署，多個版本的發佈或問題修復，只有一個master便會顯得力不從心。

2.3 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）回主分支。

2.4 TBD flow

TBD (Trunk-based Development) flow是由Paul Hammant於2013年提出的模型。
TBD flow最大的特點是所有開發都基於主幹trunk，不再有長期的開發分支，要求所有的提交儘快回到主幹，這樣可以共享最新的代碼，並且能儘可能地減少合併衝突。
如果需要發佈版本，可以基於trunk直接生成新的分支用於發佈。
TBD flow沒有pull或者push request，要求開發人員儘快把代碼提交到主幹分支，
但是TBD flow缺乏嚴格的流程來保證每一份提交代碼的質量，如果一些項目開發人員衆多且水平不一，同時工作在主分支上可能會在產品發佈時才發現不可預知的問題，
所以TBD flow更適用於需要快速迭代的產品，如果在主幹分支上發現問題，可以快速進行修復再合併回主幹分支。

2.5 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以確保主分支的健壯性。

3 - 選擇

Git代碼分支管理模型各具特點，流程只是一個輔助工具，沒有最好，只有最合適。
例如，

• 如果開發團隊規模較小又比較分散，產品發佈週期較短(例如:初創公司，或者開發的是一個網站或 Web 應用程序，在一天內可能需要發佈多個版本)，可以選擇GitHub flow或者GitLab flow；
• 如果開發團隊規模較大，產品發佈週期較長(例如:團隊超過20人，採用了月度或季度發佈週期，並且由一個團隊負責並行開發多個項目)，可以選擇Git flow，發佈週期較短可以選擇TBD flow；
• 如果開發團隊規模大，產品發佈週期長，同時對敏捷的要求比較高，可以考慮TBD++ flow。
  每個組織根據產品、項目、人員的特點找到最合適的模型纔是共同的目標。

4 - 參考信息

• 無需分支基於主幹的開發是團隊健康的重要標誌 https://www.infoq.cn/article/tFwoy4gko3vJqp5oYYEO
• 別再推薦 Git Flow 了： https://www.infoq.cn/article/i7m3UdTFLu1Lv2ai6abv
• 一個成功的Git分支模型(譯文)： https://segmentfault.com/a/1190000018087325