說到分支管理模型，令人最為熟悉的莫過於TrunkBased 和 GitFlow。

TrunkBased 模型是持續集成思想所崇尚的工作方式，它由單個master分支和許多release分支組成，每個release分支在特定版本的提交點上從master分支創建出來，用來進行上線部署和 Hotfix。在 TrunkBased 模式中，沒有顯性的feature分支。

GitFlow 模型是若幹模式的集大成者，包含一個master分支、一個develop分支、許多的feature分支、許多的release分支和 Hotfix 分支，以及許多繁瑣的合並規則。

基於這兩種模型，演變出了很多的新模型，而阿裏的AoneFlow，它基本上兼顧了 TrunkBased 的“易於持續集成”和 GitFlow 的“易於管理需求”特點，同時規避掉 GitFlow 的那些繁文縟節。

AoneFlow 只使用三種分支類型：master分支、feature分支、release分支，以及三條基本規則。

規則一，開始工作前，從master創建feature分支。

從代表最新已發布版本的master分支上創建一個通常以feature/前綴命名的特性分支，然後在這個分支上提交代碼修改。也就是說，每個工作項（可以是一個人完成，或是多個人協作完成）對應一個特性分支，所有的修改都不允許直接提交到master分支。

規則二，通過合並feature分支，形成release分支。

從master分支上拉出一條新分支，將所有本次要集成或發布的feature分支依次合並過去，從而得到release分支。release分支通常以release/前綴命名。

規則三，發布到線上正式環境後，合並相應的release分支到master分支，在master分支上添加tag，同時刪除該release分支關聯的feature分支。

為了避免在代碼倉庫裏堆積大量歷史上的feature分支，還應該清理掉已經上線部分feature分支。如果要回溯歷史版本，只需在master分支上找到相應的版本的tag即可。

除了基本規則，還有一些實際操作中不成文的技巧。比如上線後的Hotfix，正常的處理方法應該是，創建一條新的release分支，對應線上環境（相當於Hotfix分支），同時為這個分支創建臨時流水線，以保障必要的發布前檢查和冒煙測試能夠自動執行。

其實還有一種簡便方法是，將線上正式環境對應的release分支上關聯的feature分支全部清退掉，在這個release分支上直接進行修改，改完利用現成的流水線自動發布。

如果非得修一個歷史版本的Bug怎麽辦呢？那就老老實實地在master分支找到版本tag位置，然後從那個位置創建 Hotfix分支。

所謂模型，在不同的開發團隊，不同的文化，不同的項目背景情況下都有可能需要進行適當的裁剪或擴充。

開發分支管理模型之阿裏AoneFlow