前言
在我前期的項目管理的經驗中，一個項目需要維護多個產品及多個版本，這給版本與分支的管理增加了難度。前期沒有重視，使得分支太多太亂，版本也沒記錄好，引發了很多的問題。在多種分支與版本的管理模式下，最終參考阿里的AoneBased模式來管理分支。在此做個總結並分享給大家，希望可以幫助大家找到適合自己項目的版本管理方式。
背景
碰到一個較復雜的自研項目，既要做原始功能的研發，還要做產品的定制化開發。前期的版本管理大致為：
- 1、共一個主干分支master
- 2、N個特性分支==N個發布分支（特性分支開發完成后，直接轉測，直接轉為發布分支）
- 3、不定期的更新主干分支
產生的主要問題有 - 1、主干分支常常跟不上線上環境的代碼
- 2、大量的合並突沖，集成測試不友好
- 3、版本記錄混亂，功能點不明確
- 4、某功能突然要撤回時，要手動去注銷對應代碼
總之產生的問題非常多，整個項目代碼管理混亂，非常不利於維護。后整理思緒，先總結一些常見的版本管理模式。
一、TrunkBased模式
組成
一個主干分支 + 多個發布分支
使用流程
每個發布分支在特定的提交點從主干分支中拉取出來，進行線上部署和Hotfix.
缺點
多個團隊或多個產品在同一個主干分支上並行開發時，發布的時候就是災難了。需要頻繁的集成和足夠的測試覆蓋。
小結
TrunkBased這種模試應該是比較常見的。但是其多是在主干分支上開發，雖能時該保持獲取到最新的代碼，但是非常不利於后期的維護。使用場景過於局限，適合版本維護比較單一，迭代周期比較長的的項目。比如公司官網，功能不復雜，大多都是維護下圖片或動態，可以考慮這種版本管理模式。
二、OneFlow模式
此模式是TrunkBased的升級版，增加了Hotfix分支，采用多主干模式，一般是雙主干（一個主干分支+一個主干發布分支）。OneFlow在TrunkBased模式演進中，做了一此改善，分離了主干分支和發布分支，有效的規避了一些問題。但是同樣還不能滿足多版本，多產品的並行開發。
三、GitFlow模式
組成
一個主干分支+一個開發分支+N個特性分支+N個發布分支+N個Hotfix分支
使用流程
從流程圖可以看出，主干分支保持了與線上環境的代碼同步，但又有主發布分支隔離了未測試的不穩定代碼。每次項目有新需求時，從主干分支上拉取一個最新的特性分支進行開發。開發完成時合並到發布分支上進行集成與測試，發布成功后才合到主干分支中。
小結
可以看出，GitFlow版本管理模式比較符合多版本的並行開發。所以它非常受一些很注重流程的公司青睞。但是，看似不錯的模式在實現運用中也還是會出現問題。比如大量的合並沖突，集成測試不友好等。那么在如此情況下，阿里的AoneFlow模式就很好的改善了這些問題，接下來看。
四、AoneFlow模式
組成
一個主干分支+N個特性分支+N個發布分支
使用流程
從流程圖可以看出，AoneFlow模式只有一個主干分支。每次有新需求時，從當前主干分支拉取一個特性分支。多個特性分支可同步開發，到發布時間節點時，根據不同的環境合並不同的分支。如測試環境發布分支，演式環境發布分支，線上環境發布分支等。成功發布后，發布分支的代碼應合並到主干分支上。同樣，每次合並到主干分支時要打上tag，做好記錄。最后把發布分支上關聯的特性分支刪除。
小結
AoneFlow模式可以看出，對於維護不同環境和不同版本的情況下非常適用，也不會產生多余的分支，主干分支與線上環境保持一致。當我們碰到有某個功能要撤銷時，可以直接回滾到某次合 並記錄中，去除某個發布分支，合並其余分支。利於可維護。整個流程簡單有規則，輕松高效管理項目版本與分支。
總結
通過以上一系列的分析梳理，我在項目中碰到的版本管理問題得到了解決。相信大家也都能找到適合項目的管理方式。無論怎樣，大小版本的記錄是少不了的。想要做好一個項目的管理，讓項目更好的可讀可維護，我們需要做好很多細節的工作。每一個環節都尋找更優的方法。版本的管理只是其中的一部分，前路漫漫，作重而道遠。歡迎各位大佬多多指點！