在我前期的專案管理的經驗中，乙個專案需要維護多個產品及多個版本，這給版本與分支的管理增加了難度。前期沒有重視，使得分支太多太亂，版本也沒記錄好，引發了很多的問題。在多種分支與版本的管理模式下，最終參考阿里的aonebased模式來管理分支。在此做個總結並分享給大家，希望可以幫助大家找到適合自己專案的版本管理方式。
碰到乙個較複雜的自研專案，既要做原始功能的研發，還要做產品的定製化開發。前期的版本管理大致為：
一、trunkbased模式
組成
乙個主幹分支 + 多個發布分支每個發布分支在特定的提交點從主幹分支中拉取出來，進行線上部署和hotfix.多個團隊或多個產品在同乙個主幹分支上並行開發時，發布的時候就是災難了。需要頻繁的整合和足夠的測試覆蓋。trunkbased這種模試應該是比較常見的。但是其多是在主幹分支上開發，雖能時該保持獲取到最新的**，但是非常不利於後期的維護。使用場景過於侷限，適合版本維護比較單一，迭代週期比較長的的專案。比如公司官網，功能不複雜，大多都是維護下或動態，可以考慮這種版本管理模式。此模式是trunkbased的公升級版，增加了hotfix分支，採用多主幹模式，一般是雙主幹（乙個主幹分支+乙個主幹發布分支）。oneflow在trunkbased模式演進中，做了一此改善，分離了主幹分支和發布分支，有效的規避了一些問題。但是同樣還不能滿足多版本，多產品的並行開發。
三、gitflow模式
組成
乙個主幹分支+乙個開發分支+n個特性分支+n個發布分支+n個hotfix分支從流程圖可以看出，主幹分支保持了與線上環境的**同步，但又有主發布分支隔離了未測試的不穩定**。每次專案有新需求時，從主幹分支上拉取乙個最新的特性分支進行開發。開發完成時合併到發布分支上進行整合與測試，發布成功後才合到主幹分支中。
小結可以看出，gitflow版本管理模式比較符合多版本的並行開發。所以它非常受一些很注重流程的公司青睞。但是，看似不錯的模式在實現運用中也還是會出現問題。比如大量的合併衝突，整合測試不友好等。那麼在如此情況下，阿里的aoneflow模式就很好的改善了這些問題，接下來看。
四、aoneflow模式
組成乙個主幹分支+n個特性分支+n個發布分支
使用流程
從流程圖可以看出，aoneflow模式只有乙個主幹分支。每次有新需求時，從當前主幹分支拉取乙個特性分支。多個特性分支可同步開發，到發布時間節點時，根據不同的環境合併不同的分支。如測試環境發布分支，演式環境發布分支，線上環境發布分支等。成功發布後，發布分支的**應合併到主幹分支上。同樣，每次合併到主幹分支時要打上tag，做好記錄。最後把發布分支上關聯的特性分支刪除。
小結aoneflow模式可以看出，對於維護不同環境和不同版本的情況下非常適用，也不會產生多餘的分支，主幹分支與線上環境保持一致。當我們碰到有某個功能要撤銷時，可以直接回滾到某次合 並記錄中，去除某個發布分支，合併其餘分支。利於可維護。整個流程簡單有規則，輕鬆高效管理專案版本與分支。
通過以上一系列的分析梳理，我在專案中碰到的版本管理問題得到了解決。相信大家也都能找到適合專案的管理方式。無論怎樣，大小版本的記錄是少不了的。想要做好乙個專案的管理，讓專案更好的可讀可維護，我們需要做好很多細節的工作。每乙個環節都尋找更優的方法。版本的管理只是其中的一部分，前路漫漫，作重而道遠。歡迎各位大佬多多指點！
版本與分支管理
建議對於常用jira版本規劃至少保持4個，分支也同理4個，例如 假設對外正式release的分支為1.0.0，1.1.0,1.2.0,1.3.0等等。分支名 jira 版本計畫的狀態 release分支 closed 規則 例如分支名為r1.0.0 當前已經發布給客戶 或者已經正式提測 並需要最近高...
專案原始碼與專案構建產物的版本管理
工作中雜事比較多，或許沒有哪個公司會去給你專門的寫技術部落格的時間吧。我想說的是，也許會擠時間的人能夠在工作間隙抽空寫出自己對技術的感悟，一有某方面看法，立馬能夠捕捉當時想法記錄下來，至少也方便後來的整理成文，而且能夠用這種方式說服更多人認可他的觀點。而對於我，事實上我沒有寫部落格的習慣，但是我確實...
專案運作中管理與領導之辨
從專案人員的成熟度來劃分，專案至少可以分為兩類 一類是專案組的成員基本具備專案開發的各種技能 技術，溝通，流程建立等 這種情形下最需要的是管理。也就是說創造乙個好的範圍，讓每個人能很好的發揮自己的能力 第二類是專案組 成員不具備完成各種事情的技能，好多人不是不想做 而是不知道怎麼做，或者說 不知道怎...