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

說到分支管理模型，使人最爲熟悉的莫過於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分支。

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