前言

在我前期的專案管理的經驗中，一個專案需要維護多個產品及多個版本，這給版本與分支的管理增加了難度。前期沒有重視，使得分支太多太亂，版本也沒記錄好，引發了很多的問題。在多種分支與版本的管理模式下，最終參考阿里的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模式可以看出，對於維護不同環境和不同版本的情況下非常適用，也不會產生多餘的分支，主幹分支與線上環境保持一致。當我們碰到有某個功能要撤銷時，可以直接回滾到某次合 並記錄中，去除某個釋出分支，合併其餘分支。利於可維護。整個流程簡單有規則，輕鬆高效管理專案版本與分支。

總結

通過以上一系列的分析梳理，我在專案中碰到的版本管理問題得到了解決。相信大家也都能找到適合專案的管理方式。無論怎樣，大小版本的記錄是少不了的。想要做好一個專案的管理，讓專案更好的可讀可維護，我們需要做好很多細節的工作。每一個環節都尋找更優的方法。版本的管理只是其中的一部分，前路漫漫，作重而道遠。歡迎各位大佬多多指點！