前言
在我前期的專案管理的經驗中，一個專案需要維護多個產品及多個版本，這給版本與分支的管理增加了難度，前期沒有重視，使得分支太多太亂，版本也沒記錄好，引發了很多的問題，在多種分支與版本的管理模式下，最終參考阿里的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模式可以看出，對于維護不同環境和不同版本的情況下非常適用，也不會產生多余的分支，主干分支與線上環境保持一致，當我們碰到有某個功能要撤銷時，可以直接回滾到某次合 并記錄中，去除某個發布分支，合并其余分支，利于可維護，整個流程簡單有規則，輕松高效管理專案版本與分支，
總結
通過以上一系列的分析梳理，我在專案中碰到的版本管理問題得到了解決，相信大家也都能找到適合專案的管理方式，無論怎樣，大小版本的記錄是少不了的，想要做好一個專案的管理，讓專案更好的可讀可維護，我們需要做好很多細節的作業，每一個環節都尋找更優的方法，版本的管理只是其中的一部分，前路漫漫，作重而道遠，歡迎各位大佬多多指點！
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/225615.html
標籤：其他
上一篇：git 的 origin 的含義
下一篇：專案微管理15 - 首秀