理論是灰色的，生命之樹常青。
引言
任何一家公司乃至於一個小組織，只要有寫代碼的地方，就有代碼版本管理的主場，初入職場，總會遇到第一個攔路虎 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 條原則：
master分支永遠是隨時可部署發佈的- 需求新增基於
master分支，並創建一個語義化分支 - 定期推送本地分支到遠端
- 合併到
master需要提PR PR一旦經過code review無誤後即可合併到mastermaster一旦接收到合併請求，即可立即部署發佈
其大概的流程圖如下：\
圖源 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] a-successful-git-branching-model
[2] githubflow
[3] what-are-gitlab-flow-best-practices
[4] oneflow-a-git-branching-model-and-workflow
[5] 在阿里，我們如何管理代碼分支？
