Git-flow分支管理與Aone-flow分支管理對比

git-flow分支管理：

master: 主分支，主要用來版本發佈。
hotfix：線上 bug 緊急修復用到的臨時分支。這個分支用來修復主線master的BUG
release（預發佈分支）：release 分支可以認爲是 master 分支的未測試版。比如說某一期的功能全部開發完成，那麼就將 develop 分支合併到 release 分支，測試沒有問題並且到了發佈日期就合併到 master 分支，進行發佈。
develop（相當於release的預分支）：日常開發分支，該分支正常保存了開發的最新代碼。
feature：具體的功能開發分支，只與 develop 分支交互。
個人總結
優點：
1、經過多次實踐，並行特性開發良好。
2、適合大型項目開發，對小中型項目而言，過於繁雜，降低敏捷性。
3、公司協同性比較高的話適合使用，或者公司有專門的git管理部門統一管理分支。
缺點：
1、從項目開始到上線過程中需要開的新分支過多不易維護，而且多分支容易出錯。
2、對於測試來說增加工作量，develop一套分支代碼會同時承載兩個環境，一個dev環境供開發使用，一個test環境供測試使用。
所以測試過程先是開發人員在feature分支自測，然後是測試人員在dev環境測試，之後是在release環境還要測試，最後才能合到master上線。
當hotfix分支合併入到release分支的時候,release分支必須得再次驗證，縱使release上的功能全都驗證通過。（繁瑣的自測和測試人員的重複測試流程，測試人員比較少或者有其他項目需要測試）拖長項目的迭代週期。
3、對於項目經理而言，管理這些分支需要消耗比較多的精力，需要根據不同情況選擇性的去拉取或者刪除不同的分支，不僅在feature分支合併代碼到dev時候，如果有並行訴求需及時判斷並行中哪條是需要延時合入的，這在敏捷開發或者快速迭代過程中會有工作負擔。
而且在release分支上上行合併和下行合併時也會有問題，這裏開發人員可以在release上進行修改代碼。針對線上bug根據緊急程度由經理決定決定是否使用hotfix分支。
4、分支越多，生命週期越短，這種出錯的概率就越大。merge代碼總是痛苦和易錯的。在軟件開發的世界裏，如果一件事很痛苦，那就頻繁地去做它。feature branch這個實踐本身阻礙了頻繁的merge: 因爲不同feature branch只能從master或develop分支pull代碼，而在較長週期的開發完成後才被merge回master。
也就是說相對不同的feature branch，develop上的代碼永遠是過時的。如果feature開發的平均時間是一個月，feature A所基於的代碼可能在一個月前已經被feature B所修改掉了，這一個月來一直是基於錯誤的代碼進行開發，而直到feature branch B被merge回develop才能獲得反饋，到最後merge的成本是非常高的。
5、git-flow大量的合併衝突和對集成測試不友好。
Aone-flow分支管理：
它基本上兼顧了 TrunkBased 的「易於持續集成」和 GitFlow 的「易於管理需求」特點，同時規避掉 GitFlow 的那些繁文縟節。
AoneFlow 只使用三種分支類型：master分支、feature分支、release分支，以及三條基本規則
規則一（開始工作前，從主幹創建特性分支）
AoneFlow 的特性分支基本借鑑 GitFlow，沒有什麼特別之處。每當開始一件新的工作項（比如新的功能或是待解決的問題）的時候，從代表最新已發佈版本的主幹上創建一個通常以feature/前綴命名的特性分支，然後在這個分支上提交代碼修改。也就是說，每個工作項（可以是一個人完成，或是多個人協作完成）對應一個特性分支，所有的修改都不允許直接提交到主幹

規則二（通過合併特性分支，形成發佈分支）
AoneFlow 的發佈分支設計十分巧妙，可謂整個體系的精髓。GitFlow 先將已經完成的特性分支合併回公共主線（即開發分支），然後從公共主線拉出發佈分支。TrunkBased 同樣是等所有需要的特性都在主幹分支上開發完成，然後從主幹分支的特定位置拉出發佈分支。而 AoneFlow 的思路是，從主幹上拉出一條新分支，將所有本次要集成或發佈的特性分支依次合併過去，從而得到發佈分支。發佈分支通常以release/前綴命名。

規則三，發佈到線上正式環境後，合併相應的發佈分支到主幹，在主幹添加標籤，同時刪除該發佈分支關聯的特性分支。

當一條發佈分支上的流水線完成了一次線上正式環境的部署，就意味着相應的功能真正的發佈了，此時應該將這條發佈分支合併到主幹。爲了避免在代碼倉庫裏堆積大量歷史上的特性分支，還應該清理掉已經上線部分特性分支。與 GitFlow 相似，主幹分支上的最新版本始終與線上版本一致，如果要回溯歷史版本，只需在主幹分支上找到相應的版本標籤即可。

除了基本規則，還有一些實際操作中不成文的技巧。比如上線後的 Hotfix，正常的處理方法應該是，創建一條新的發佈分支，對應線上環境（相當於 Hotfix 分支），同時爲這個分支創建臨時流水線，以保障必要的發佈前檢查和冒煙測試能夠自動執行。但其實還有一種簡便方法是，將線上正式環境對應的發佈分支上關聯的特性分支全部清退掉，在這個發佈分支上直接進行修改，改完利用現成的流水線自動發佈。如果非得修一個歷史版本的 Bug 怎麼辦呢？那就老老實實的在主幹分支找到版本標籤位置，然後從那個位置創建 Hotfix 分支吧，不過由於阿里的產品大多是線上 SaaS 業務，這樣的場景並不多見。

正是這些簡單的規則，組成了 AoneFlow 獨樹一幟的核心套路。

個人總結： 規則易懂，三條規則。 它基本上兼顧了 TrunkBased 的「易於持續集成」和 GitFlow 的「易於管理需求」特點，同時規避掉 GitFlow 的那些繁文縟節。 AoneFlow 只使用三種分支類型：master分支、feature分支、release分支，以及三條基本規則。 一個主幹分支+N個特性分支+N個發佈分支 相對git-flow而言的優勢： 1、AoneFlow 的發佈分支是相對固定的，因此相比 GitFlow 更易於進行持續集成。 2、經過阿里團隊長期實踐，穩定性很高。項目管理相比卻更加容易和高效，去除一些繁瑣步驟。 3、每次有新需求時，從當前主幹分支拉取一個特性分支。多個特性分支可同步開發，到發佈時間節點時，根據不同的環境合併不同的分支。 4、對於維護不同環境和不同版本的情況下非常適用，不會產生多餘的分支，主幹分支與線上環境保持一致。 使用Aone-flow最好有良好的代碼規範和配套的工具，比如：用於線上發佈的代碼，不可以使用包含「SNAPSHOT 版本」（即未正式發佈版本）的依賴包，從而確保每次構建出的產物都是一致的等等細節需要關注。工具考慮的話可以瞭解一下阿里的雲效。 總體而言，Aone-flow相對於不同項目的管理而言，相比git-flow我覺得更加高效。分支方面可由相應組長或者項目經理進行管理，工作量也不算大。