項目版本與分支管理之阿里AoneFlow模式分析

前言

在我前期的項目管理的經驗中，一個項目須要維護多個產品及多個版本，這給版本與分支的管理增長了難度。前期沒有重視，使得分支太多太亂，版本也沒記錄好，引起了不少的問題。在多種分支與版本的管理模式下，最終參考阿里的AoneBased模式來管理分支。在此作個總結並分享給你們，但願能夠幫助你們找到適合本身項目的版本管理方式。

背景

碰到一個較複雜的自研項目，既要作原始功能的研發，還要作產品的定製化開發。前期的版本管理大體爲：

• 一、共一個主幹分支master
• 二、N個特性分支==N個發佈分支（特性分支開發完成後，直接轉測，直接轉爲發佈分支）
• 三、不按期的更新主幹分支
  產生的主要問題有
• 一、主幹分支經常跟不上線上環境的代碼
• 二、大量的合併突衝，集成測試不友好
• 三、版本記錄混亂，功能點不明確

• 四、某功能忽然要撤回時，要手動去註銷對應代碼
  總之產生的問題很是多，整個項目代碼管理混亂，很是不利於維護。後整理思緒，先總結一些常見的版本管理模式。

  1、TrunkBased模式

  組成

  一個主幹分支 + 多個發佈分支

  使用流程

  每一個發佈分支在特定的提交點從主幹分支中拉取出來，進行線上部署和Hotfix.

  缺點

  多個團隊或多個產品在同一個主幹分支上並行開發時，發佈的時候就是災難了。須要頻繁的集成和足夠的測試覆蓋。

  小結

  TrunkBased這種模試應該是比較常見的。可是其可能是在主幹分支上開發，雖能時該保持獲取到最新的代碼，可是很是不利於後期的維護。使用場景過於侷限，適合版本維護比較單一，迭代週期比較長的的項目。好比公司官網，功能不復雜，大多都是維護下圖片或動態，能夠考慮這種版本管理模式。

  2、OneFlow模式

  此模式是TrunkBased的升級版，增長了Hotfix分支，採用多主幹模式，通常是雙主幹（一個主幹分支+一個主幹發佈分支）。OneFlow在TrunkBased模式演進中，作了一此改善，分離了主幹分支和發佈分支，有效的規避了一些問題。可是一樣還不能知足多版本，多產品的並行開發。

  3、GitFlow模式

  組成

  一個主幹分支+一個開發分支+N個特性分支+N個發佈分支+N個Hotfix分支

  使用流程

  從流程圖能夠看出，主幹分支保持了與線上環境的代碼同步，但又有主發佈分支隔離了未測試的不穩定代碼。每次項目有新需求時，從主幹分支上拉取一個最新的特性分支進行開發。開發完成時合併到發佈分支上進行集成與測試，發佈成功後才合到主幹分支中。

  小結

  能夠看出，GitFlow版本管理模式比較符合多版本的並行開發。因此它很是受一些很注重流程的公司青睞。可是，看似不錯的模式在實現運用中也仍是會出現問題。好比大量的合併衝突，集成測試不友好等。那麼在如此狀況下，阿里的AoneFlow模式就很好的改善了這些問題，接下來看。

  4、AoneFlow模式

  組成

  一個主幹分支+N個特性分支+N個發佈分支

  使用流程

  
  從流程圖能夠看出，AoneFlow模式只有一個主幹分支。每次有新需求時，從當前主幹分支拉取一個特性分支。多個特性分支可同步開發，到發佈時間節點時，根據不一樣的環境合併不一樣的分支。如測試環境發佈分支，演式環境發佈分支，線上環境發佈分支等。成功發佈後，發佈分支的代碼應合併到主幹分支上。一樣，每次合併到主幹分支時要打上tag，作好記錄。最後把發佈分支上關聯的特性分支刪除。

  小結

  AoneFlow模式能夠看出，對於維護不一樣環境和不一樣版本的狀況下很是適用，也不會產生多餘的分支，主幹分支與線上環境保持一致。當咱們碰到有某個功能要撤銷時，能夠直接回滾到某次合 並記錄中，去除某個發佈分支，合併其他分支。利於可維護。整個流程簡單有規則，輕鬆高效管理項目版本與分支。

總結

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