理論是灰色的，生命之樹常青。

引言

任何一家公司乃至於一個小組織，只要有寫程式碼的地方，就有程式碼版本管理的主場，初入職場，總會遇到第一個攔路虎git管理流程，但是每一個企業似乎都有自己的git管理流程，倘若我們能掌握常用的git分支管理模型，那麼無論碰到什麼樣的git管理流程，只不過都是這些管理模型的衍生與簡化而已。

背景

目前筆者所在的前端部門，技術棧是React & RN為主，Vue為輔，也就是說React和Vue雙棧共存，可以說是研發環境比較複雜了，運維部門也制定了相應的git管理模型，不過也是比較通用的，那麼如何制定一個符合前端部門的git管理模型尤為重要，且不可與運維部門的管理模型相沖突，由此便誕生了此篇文章。

Git Flow

由著名大佬 Vincent Driessen 在《A successful Git branching model》一文中，提出影響深遠的git程式碼管理模型，在現如今依然許多中大型企業在沿用，下面是他提出的流程圖：

優點：分支管理嚴格，程式碼合併清晰，適合於中大型團隊應用。
缺點：分支流程過多反而也是一種缺點

GitHub Flow

GitHub於 2011 年建立，遵循以下 6 條原則：

1. master分支永遠是隨時可部署釋出的
2. 需求新增基於master分支，並建立一個語義化分支
3. 定期推送本地分支到遠端
4. 合併到master需要提PR
5. PR一旦經過code review無誤後即可合併到master
6. master一旦接收到合併請求，即可立即部署釋出

其大概的流程圖如下：

圖源gaboesquivel.com

優點：分支足夠簡單，且符合人類思維邏輯，適用於持續釋出場景
缺點：針對多版本產品線則不適用

GitLab Flow

GitLab在 2014 年提出11條最佳實踐，更多請點選這裡，其相對GitHub增加了環境分支，且程式碼必須由上游（master）向下游（staging）發展，並且針對持續釋出和版本釋出都提出了相應的準則，下面是其大致流程圖：

優點：git提交歷史更加清晰、簡潔與易讀
缺點：對開發人員的能力提出了更高的要求，當存在多產品線時，和Git Flow相比平分秋色

TrunkBased

研發團隊只在master分支進行功能開發，當達到釋出的條件時，直接遷出一個只讀分支釋出，只讀分支顧名思義就是不接收任何新程式碼合併，以及在只讀分支上進行修改；當研發人員相對較多時則可以使用可擴充套件版本，增加了功能分支，但是功能分支不超過兩三天則必須要合併到master分支，其大致的流程圖如下：

優點：簡單清晰，單兵作戰最佳選擇，適合維護後期超穩定的專案
缺點：不適用多版本共存的專案

OneFlow

Adam Ruka於2017年提出，可以簡單的理解為Git Flow的簡化版本，除了develop開發分支和最新發布master分支，其餘皆是臨時分支，一旦開發完成即可刪除臨時分支，其中具體細則可檢視這裡，下面是其大致流程圖：

優點：單一版本首選，git提交歷史簡介清晰易讀
缺點：不適合持續交付或持續部署的專案，也不適用多版本共存的專案

AoneFlow

由阿里巴巴技術專家林帆基於TrunkBased和GitFlow提出的一種新改進，其主要分為三種分支型別：主幹分支、特性分支以及釋出分支，並且提出了三個基本準則：

1. 主幹建立特性分支，且不允許合併回主幹分支
2. 合併特性分支，形成釋出分支
3. 釋出到線上正式環境後，合併相應的釋出分支到主幹，在主幹新增標籤，同時刪除該釋出分支關聯的特性分支

下面是其大致的流程圖：

優點：靈活易用，通過組合生成分支往往可以實現多種高階玩法
缺點：複雜度稍高，如果沒有配套的工具規範往往會出現“無效分支”的出現

總結

介紹了眾多的分支管理模型，那麼我們該如何挑選適合自己團隊的方案呢？在這裡製作了一個思維導航圖，詳情如下：

參考：
[1]a-successful-git-branching-model
[2]githubflow
[3]what-are-gitlab-flow-best-practices
[4]oneflow-a-git-branching-model-and-workflow
[5]在阿里，我們如何管理程式碼分支？