引言

網絡上版本管理系統(tǒng)之爭持久而喧囂彤悔，依照聲量來講目前應該是Git占了較大的優(yōu)勢浪蹂。不過我們本文的關注點在于代碼的分支管理模型吼拥，因為大家無論是用SVN或者Git，目的是為了解決研發(fā)過程管理中的實際問題螃诅。我這里整理幾種分支管理模型，這樣大家可以對照自己的痛點選擇合適的模型状囱。不過并不是最靈活的方案就最好术裸，靈活意味著分支的管理和具體研發(fā)學習曲線都更復雜。

我先根據實際生產過程中企業(yè)面臨的問題列出一個清單：

• 學習曲線（Complexity）

  企業(yè)都希望研發(fā)團隊能夠快投入生產亭枷，而在版本管理這種“小事”不要花費太多精力袭艺。

• 需求變更（Release）

  企業(yè)在一個迭代過程中是否能夠完全不進行需求的變更，無論你們的周期是兩周叨粘、一個月猾编、或者一季度。

• 線上修正（Hotfix）

  系統(tǒng)目前是否已經非常穩(wěn)定升敲，不存在需要發(fā)布線上修正的可能答倡。

• 多環(huán)境（CI/CD）

  企業(yè)是否存在多環(huán)境的要求（測試、預發(fā)布驴党、正式等）

• 長期需求（Long-Lived Version-control Story）

  企業(yè)是否存在一個大需求可能要持續(xù)數(shù)個迭代瘪撇。（例如底層的基礎業(yè)務模型擴展，增加新的數(shù)據隔離標識字段港庄，涉及到系統(tǒng)底層或者全系統(tǒng)業(yè)務邏輯的變更倔既。這里列這種需求并不是說必須支持，有些普通需求由于錯誤的技術方案/市場的變化等情況就會變化成這樣的需求鹏氧，所以綜合考慮邊界情況叉存。）

另外也交代一下我所在的公司背景：

我們是一家企業(yè)內部學習培訓的人力資源SAAS管理平臺，對于平臺改進有自己的規(guī)劃和目標度帮，但是又面臨著大客戶的定制化需求以及交付時間壓力歼捏。技術棧還是Java和.Net 雙棧并存稿存，所以可以說是最復雜的研發(fā)環(huán)境了。我們也慢慢衍生出了自己的一套改進的代碼版本管理模型瞳秽。

TrunkBased

原理^[1]：研發(fā)團隊在名稱為 Trunk 的單一分支進行開發(fā)瓣履，當開發(fā)工作到一定階段的時候達到可發(fā)布條件后，切出Release分支進行發(fā)布练俐，并且Release分支是不可以修改的僅僅做發(fā)布使用袖迎。大部分SVN用戶是基于本模型進行開發(fā)。

適合小團隊的模型腺晾，大家都直接在Trunk上進行開發(fā)

Simple TrunkBased

適合較大團隊的模型燕锥，大家切出短期的特性分支進行開發(fā)，完成后合并回Trunk悯蝉。

Complex TrunkBased

適用場景：適合于單一穩(wěn)定產品線归形，迭代排期穩(wěn)定，需求邊界完全可控的團隊鼻由。

優(yōu)點：模型簡單

缺點：

• 線上修正：按照上圖目前系統(tǒng)已經發(fā)布了12.1暇榴，下一個迭代也在開發(fā)中，線上發(fā)現(xiàn)了問題蕉世。由于Release分支是禁止修改的蔼紧，而Trunk此時包含了新的特性代碼無法發(fā)布，就造成了線上異常無法修復狠轻。

• 需求變更：無法支持奸例，已經提交到Trunk的內容抽離很困難。

• 多環(huán)境：無法支持

• 長期需求：無法支持

總結：Trunk Based最大的優(yōu)勢就是清晰簡單向楼，付出的代價就是靈活性哩至，基本可以說不存在任何靈活性。適用的場景我覺得是進入到后期維護的大型系統(tǒng)蜜自，不會做太多的變更并且不會有太多的突發(fā)問題菩貌。

GitFlow

GitFlow來源應該是 Vincent Driessen 在2010年1月發(fā)表的這篇《A successful Git branching model》，基本是現(xiàn)在Git中最出名的流程管理方法了重荠。

GitFlow

這張圖相信大家都不陌生箭阶。

原理：

主要分為5個分支

• master分支存放所有正式發(fā)布的版本，可以作為項目歷史版本記錄分支戈鲁，不直接提交代碼仇参。僅用于保持一個對應線上運行代碼的 code base。

• develop分支為主開發(fā)分支婆殿，一般不直接提交代碼

• feature分支為新功能分支诈乒，feature分支都是基于develop創(chuàng)建的，開發(fā)完成后會合并到develop分支上婆芦。同時存在多個

• release分支基于最新develop分支創(chuàng)建怕磨，當新功能足夠發(fā)布一個新版本(或者接近新版本發(fā)布的截止日期)喂饥，從develop分支創(chuàng)建一個release分支作為新版本的起點，用于測試肠鲫，所有的測試bug在這個分支改员帮。測試完成后合并到master并打上版本號，同時也合并到develop导饲，更新最新開發(fā)分支捞高。(一旦打了release分支之后不要從develop分支上合并新的改動到release分支)，同一時間只有1個渣锦，生命周期很短硝岗，只是為了發(fā)布。

• hotfix分支基于master分支創(chuàng)建袋毙，對線上版本的bug進行修復型檀，完成后直接合并到master分支和develop分支，如果當前還有新功能release分支娄猫，也同步到release分支上生闲。同一時間只有1個，生命周期較短碍讯。

適用場景：處于前中期的大型項目悬蔽，人員較多管理場景較復雜蝎困，但是迭代相對穩(wěn)定，周期內不會頻繁的變更需求禾乘，盡量不要開長需求分支。

優(yōu)點：

能夠支持線上修正虽缕、多環(huán)境

缺點：

• 復雜度稍高

• 需求變更：不夠靈活，由于主分支實際上是基于develop氮趋，那意味著一旦代碼提交上去，一段時間后需要撤銷（本次迭代不發(fā)布）就比較困難

總結：Gitflow已經很偏向互聯(lián)網風格的代碼管理剩胁，考慮到了多環(huán)境、線上修正昵观。而且現(xiàn)在很多IDE或者工具有整合了GitFlow的插件使用起來會更簡單舌稀。對于有良好規(guī)劃和進度控制的項目，應該是已經夠用了建车。但是對于一些有交付日期的扩借，但是需求池可以調整的項目可能還不夠靈活。

AoneFlow

阿里的研發(fā)效能事業(yè)部專家基于TrunkBased和GitFlow提出了一套新思路：AoneFlow缤至。

原理：AoneFlow 只使用三種分支類型：主干分支潮罪、特性分支、發(fā)布分支领斥，以及三條基本規(guī)則嫉到。

1. 開始工作前，從主干創(chuàng)建特性分支月洛。

Step1

2. 通過合并特性分支何恶，形成發(fā)布分支。

Step2

3. 發(fā)布到線上正式環(huán)境后嚼黔，合并相應的發(fā)布分支到主干细层，在主干添加標簽，同時刪除該發(fā)布分支關聯(lián)的特性分支唬涧。

Step3

缺點：

• 復雜度稍高

• 多環(huán)境：由于沒有develop分支所以可能測試環(huán)境構建會有一些問題疫赎。

優(yōu)點：

• 線上環(huán)境，長期需求都是支持的

總結：AoneFlow最重要的點碎节，就是保證master分支可用和隨時可發(fā)布捧搞，其他可能都是臨時分支。所以取名的時候應該是Ali-One-Flow狮荔，這個含義胎撇。臨時分支的組裝就有很多種玩法了，需要企業(yè)根據自己的需要來定制處理殖氏。

OneFlow

OneFlow我找到兩個版本晚树，一個是國內版本，一個是國外的版本雅采。

國內版本：

原理：此模式是TrunkBased的升級版爵憎，增加了Hotfix分支，采用多主干模式总滩，一般是雙主干（一個主干分支+一個主干發(fā)布分支）纲堵。OneFlow在TrunkBased模式演進中，做了一此改善闰渔，分離了主干分支和發(fā)布分支席函，有效的規(guī)避了一些問題。但是同樣還不能滿足多版本冈涧，多產品的并行開發(fā)茂附。

國外版本：

原理：此模式是GitFlow的簡化版本正蛙，但是（作者認為）并不比GitFlow遜色营曼。主要也就是雙分支^[2]，除了主干分支锻全，只會額外保持一個分支鳄厌，在不同的階段切除特性妈踊、發(fā)布廊营、修正分支

OneFlow

而且還提供了變種版本露筒，master+develop 雙主干分支的模式。

總結：國外版本的OneFlow發(fā)表在2017年荸哟，我覺得他確定了基于一個瞬捕，最多兩個的固定分支進行開發(fā)這種原則肪虎。提供了企業(yè)版本管理過程中的最佳實踐原則扇救，（我覺得）也啟發(fā)了AoneFlow這種優(yōu)秀的Flow迅腔。

ExeFlow

ExeFlow是我們公司目前在使用的代碼管理流程的名稱靠娱，主要是吸取了AoneFlow的思想像云，同時根據我們自己的環(huán)境進行一些流程和分支的固化蚂夕。

要理解這個Flow流程婿牍，首先基于我們的實際工作場景：

我們的系統(tǒng)由于主要是面向大型企業(yè)內部使用等脂，存在復雜的分發(fā)流程和權限控制慎菲，經過長時間的累積業(yè)務模型也很復雜各種關聯(lián)和引用锨并，所以有一些大型任務的開發(fā)周期可能會比較長，到達2-3個月的周期解幼。

我們的迭代周期正常是1個月撵摆。流程大概如下：

• 上月末進行迭代計劃評估與安排特铝，這里會確認下月迭代目標的Story內容與數(shù)據壹瘟。各自主管進行子任務的拆分評估與排期稻轨。

• 開發(fā)時間一般是2周，我們基本是會在月中設定研發(fā)截止線政冻，所有研發(fā)任務要在截止線前完成提測线欲。期間有完成的任務可以隨時提測李丰。【涉及分支：Feature逆屡，Local，Develop】

• 完整的系統(tǒng)集成測試時間一般是安排在第三周砍的，測試會進行全面的測試廓鞠。本周研發(fā)的主要任務一方面是處理Bug谣旁，一方面可以介入下月迭代大項的需求說明與分析∑雒牵【涉及分支：Feature浪感，Local饼问，Develop】

• 第四周的前三天，我們會切出預發(fā)布的分支在第四周周一時峻堰，會給出明確本次能夠上線的Story List盅视，不在清單內的都不允許合并只預發(fā)布環(huán)境（也就是我們實際上運行需求在預發(fā)布之前仍舊有變更左冬，只要測試人員通過了集成測試環(huán)境纸型，就可以合并并且發(fā)布），本次發(fā)版的具體內容和通知也是當天發(fā)出除破」宸悖【涉及分支：Feature光坝，Release】

• 發(fā)版一般安排在當月的最后一個周四（為了防止有線上問題，所以不能是周五第二天會沒有人員值守）性含≡Ч撸【涉及分支：Release芝发，Master】

主要經歷了2個大版本的變化

版本1，基本是參考GitFlow

ExeFlow - version 1

這個版本的固定獨立分支是三條：Master格郁，Develop理张，Local雾叭。核心在于Release分支還是由Develop建立落蝙，對于需求變更的支持性不夠靈活。

版本2移迫，是參考AoneFlow

ExeFlow - version 2

（上圖就是使用gitgraphjs繪制）

這個版本的固定獨立分支也還是是三條：Master管行，Develop捐顷，Local迅涮。

但是核心差異在于Release分支是由Master建立，并且合并需要上線的Feature分支叮姑，而Release分支在我們企業(yè)的流程中只會存在2-3天的時間。

總結：其實是比較復雜的流程极颓，而且研發(fā)的操作的內容實際更多。我們還要鎖定某些分支讼昆，設定權限管理浸赫。但是解決了我們的問題既峡，所以從上到下都能替換到復雜流程帶來的好處碧查。

綜述

如果你完整看完了這篇文章忠售，實際上現(xiàn)在需要的并不是馬上選擇當前企業(yè)應該選用哪一種Flow管理模型稻扬，而是認真的思考企業(yè)實際面臨的問題和痛點。越靈活的流程越復雜盼砍，對于研發(fā)人員初期的接收難度就越高浇坐。我們想真正讓研發(fā)團隊理解并接受某個管理模型黔宛，最重要的是這個東西解決了企業(yè)面臨的問題臀晃。才能讓管理層积仗、研發(fā)自身體會到好處寂曹。

我看了很多版本管理軟件的對比，無論是抬Svn打Git或者反之漱挚，我覺得都對也都不對旨涝。因為無論管理或者技術白华，本身沒有對錯優(yōu)劣弧腥，問題是場景。如果一個簡單穩(wěn)定的后期維護項目管搪，強推復雜的管理流程更鲁，效果不會好澡为，因為沒有解決任何問題缀壤，只會引入問題纠亚。

管理的核心在于解決問題蒂胞，而不是管理行為本身。

1. 引用自 Trunk Based Development Introduction ?

2. 畫圖工具是使用gitgraphjs ?