引言

網(wǎng)絡(luò)上版本管理系統(tǒng)之爭(zhēng)持久而喧囂，依照聲量來(lái)講目前應(yīng)該是Git占了較大的優(yōu)勢(shì)。不過(guò)我們本文的關(guān)注點(diǎn)在于代碼的分支管理模型，因?yàn)榇蠹覠o(wú)論是用SVN或者Git，目的是為了解決研發(fā)過(guò)程管理中的實(shí)際問(wèn)題。我這里整理幾種分支管理模型，這樣大家可以對(duì)照自己的痛點(diǎn)選擇合適的模型。不過(guò)并不是最靈活的方案就最好，靈活意味著分支的管理和具體研發(fā)學(xué)習(xí)曲線都更復(fù)雜。

我先根據(jù)實(shí)際生產(chǎn)過(guò)程中企業(yè)面臨的問(wèn)題列出一個(gè)清單：

• 學(xué)習(xí)曲線（Complexity）

  企業(yè)都希望研發(fā)團(tuán)隊(duì)能夠快投入生產(chǎn)，而在版本管理這種“小事”不要花費(fèi)太多精力。

• 需求變更（Release）

  企業(yè)在一個(gè)迭代過(guò)程中是否能夠完全不進(jìn)行需求的變更，無(wú)論你們的周期是兩周、一個(gè)月、或者一季度。

• 線上修正（Hotfix）

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

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

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

• 長(zhǎng)期需求（Long-Lived Version-control Story）

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

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

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

TrunkBased

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

適合小團(tuán)隊(duì)的模型，大家都直接在Trunk上進(jìn)行開發(fā)

Simple TrunkBased

適合較大團(tuán)隊(duì)的模型，大家切出短期的特性分支進(jìn)行開發(fā)，完成后合并回Trunk。

Complex TrunkBased

適用場(chǎng)景：適合于單一穩(wěn)定產(chǎn)品線，迭代排期穩(wěn)定，需求邊界完全可控的團(tuán)隊(duì)。

優(yōu)點(diǎn)：模型簡(jiǎn)單

缺點(diǎn)：

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

• 需求變更：無(wú)法支持，已經(jīng)提交到Trunk的內(nèi)容抽離很困難。

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

• 長(zhǎng)期需求：無(wú)法支持

總結(jié)：Trunk Based最大的優(yōu)勢(shì)就是清晰簡(jiǎn)單，付出的代價(jià)就是靈活性，基本可以說(shuō)不存在任何靈活性。適用的場(chǎng)景我覺(jué)得是進(jìn)入到后期維護(hù)的大型系統(tǒng)，不會(huì)做太多的變更并且不會(huì)有太多的突發(fā)問(wèn)題。

GitFlow

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

GitFlow

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

原理：

主要分為5個(gè)分支

• master分支存放所有正式發(fā)布的版本，可以作為項(xiàng)目歷史版本記錄分支，不直接提交代碼。僅用于保持一個(gè)對(duì)應(yīng)線上運(yùn)行代碼的 code base。

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

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

• release分支基于最新develop分支創(chuàng)建，當(dāng)新功能足夠發(fā)布一個(gè)新版本(或者接近新版本發(fā)布的截止日期)，從develop分支創(chuàng)建一個(gè)release分支作為新版本的起點(diǎn)，用于測(cè)試，所有的測(cè)試bug在這個(gè)分支改。測(cè)試完成后合并到master并打上版本號(hào)，同時(shí)也合并到develop，更新最新開發(fā)分支。(一旦打了release分支之后不要從develop分支上合并新的改動(dòng)到release分支)，同一時(shí)間只有1個(gè)，生命周期很短，只是為了發(fā)布。

• hotfix分支基于master分支創(chuàng)建，對(duì)線上版本的bug進(jìn)行修復(fù)，完成后直接合并到master分支和develop分支，如果當(dāng)前還有新功能release分支，也同步到release分支上。同一時(shí)間只有1個(gè)，生命周期較短。

適用場(chǎng)景：處于前中期的大型項(xiàng)目，人員較多管理場(chǎng)景較復(fù)雜，但是迭代相對(duì)穩(wěn)定，周期內(nèi)不會(huì)頻繁的變更需求，盡量不要開長(zhǎng)需求分支。

優(yōu)點(diǎn)：

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

缺點(diǎn)：

• 復(fù)雜度稍高

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

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

AoneFlow

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

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

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

Step1

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

Step2

3. 發(fā)布到線上正式環(huán)境后，合并相應(yīng)的發(fā)布分支到主干，在主干添加標(biāo)簽，同時(shí)刪除該發(fā)布分支關(guān)聯(lián)的特性分支。

Step3

缺點(diǎn)：

• 復(fù)雜度稍高

• 多環(huán)境：由于沒(méi)有develop分支所以可能測(cè)試環(huán)境構(gòu)建會(huì)有一些問(wèn)題。

優(yōu)點(diǎn)：

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

總結(jié)：AoneFlow最重要的點(diǎn)，就是保證master分支可用和隨時(shí)可發(fā)布，其他可能都是臨時(shí)分支。所以取名的時(shí)候應(yīng)該是Ali-One-Flow，這個(gè)含義。臨時(shí)分支的組裝就有很多種玩法了，需要企業(yè)根據(jù)自己的需要來(lái)定制處理。

OneFlow

OneFlow我找到兩個(gè)版本，一個(gè)是國(guó)內(nèi)版本，一個(gè)是國(guó)外的版本。

國(guó)內(nèi)版本：

原理：此模式是TrunkBased的升級(jí)版，增加了Hotfix分支，采用多主干模式，一般是雙主干（一個(gè)主干分支+一個(gè)主干發(fā)布分支）。OneFlow在TrunkBased模式演進(jìn)中，做了一此改善，分離了主干分支和發(fā)布分支，有效的規(guī)避了一些問(wèn)題。但是同樣還不能滿足多版本，多產(chǎn)品的并行開發(fā)。

國(guó)外版本：

原理：此模式是GitFlow的簡(jiǎn)化版本，但是（作者認(rèn)為）并不比GitFlow遜色。主要也就是雙分支^[2]，除了主干分支，只會(huì)額外保持一個(gè)分支，在不同的階段切除特性、發(fā)布、修正分支

OneFlow

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

總結(jié)：國(guó)外版本的OneFlow發(fā)表在2017年，我覺(jué)得他確定了基于一個(gè)，最多兩個(gè)的固定分支進(jìn)行開發(fā)這種原則。提供了企業(yè)版本管理過(guò)程中的最佳實(shí)踐原則，（我覺(jué)得）也啟發(fā)了AoneFlow這種優(yōu)秀的Flow。

ExeFlow

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

要理解這個(gè)Flow流程，首先基于我們的實(shí)際工作場(chǎng)景：

我們的系統(tǒng)由于主要是面向大型企業(yè)內(nèi)部使用，存在復(fù)雜的分發(fā)流程和權(quán)限控制，經(jīng)過(guò)長(zhǎng)時(shí)間的累積業(yè)務(wù)模型也很復(fù)雜各種關(guān)聯(lián)和引用，所以有一些大型任務(wù)的開發(fā)周期可能會(huì)比較長(zhǎng)，到達(dá)2-3個(gè)月的周期。

我們的迭代周期正常是1個(gè)月。流程大概如下：

• 上月末進(jìn)行迭代計(jì)劃評(píng)估與安排，這里會(huì)確認(rèn)下月迭代目標(biāo)的Story內(nèi)容與數(shù)據(jù)。各自主管進(jìn)行子任務(wù)的拆分評(píng)估與排期。

• 開發(fā)時(shí)間一般是2周，我們基本是會(huì)在月中設(shè)定研發(fā)截止線，所有研發(fā)任務(wù)要在截止線前完成提測(cè)。期間有完成的任務(wù)可以隨時(shí)提測(cè)?！旧婕胺种В篎eature，Local，Develop】

• 完整的系統(tǒng)集成測(cè)試時(shí)間一般是安排在第三周，測(cè)試會(huì)進(jìn)行全面的測(cè)試。本周研發(fā)的主要任務(wù)一方面是處理Bug，一方面可以介入下月迭代大項(xiàng)的需求說(shuō)明與分析?！旧婕胺种В篎eature，Local，Develop】

• 第四周的前三天，我們會(huì)切出預(yù)發(fā)布的分支在第四周周一時(shí)，會(huì)給出明確本次能夠上線的Story List，不在清單內(nèi)的都不允許合并只預(yù)發(fā)布環(huán)境（也就是我們實(shí)際上運(yùn)行需求在預(yù)發(fā)布之前仍舊有變更，只要測(cè)試人員通過(guò)了集成測(cè)試環(huán)境，就可以合并并且發(fā)布），本次發(fā)版的具體內(nèi)容和通知也是當(dāng)天發(fā)出?！旧婕胺种В篎eature，Release】

• 發(fā)版一般安排在當(dāng)月的最后一個(gè)周四（為了防止有線上問(wèn)題，所以不能是周五第二天會(huì)沒(méi)有人員值守）。【涉及分支：Release，Master】

主要經(jīng)歷了2個(gè)大版本的變化

版本1，基本是參考GitFlow

ExeFlow - version 1

這個(gè)版本的固定獨(dú)立分支是三條：Master，Develop，Local。核心在于Release分支還是由Develop建立，對(duì)于需求變更的支持性不夠靈活。

版本2，是參考AoneFlow

ExeFlow - version 2

（上圖就是使用gitgraphjs繪制）

這個(gè)版本的固定獨(dú)立分支也還是是三條：Master，Develop，Local。

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

總結(jié)：其實(shí)是比較復(fù)雜的流程，而且研發(fā)的操作的內(nèi)容實(shí)際更多。我們還要鎖定某些分支，設(shè)定權(quán)限管理。但是解決了我們的問(wèn)題，所以從上到下都能替換到復(fù)雜流程帶來(lái)的好處。

綜述

如果你完整看完了這篇文章，實(shí)際上現(xiàn)在需要的并不是馬上選擇當(dāng)前企業(yè)應(yīng)該選用哪一種Flow管理模型，而是認(rèn)真的思考企業(yè)實(shí)際面臨的問(wèn)題和痛點(diǎn)。越靈活的流程越復(fù)雜，對(duì)于研發(fā)人員初期的接收難度就越高。我們想真正讓研發(fā)團(tuán)隊(duì)理解并接受某個(gè)管理模型，最重要的是這個(gè)東西解決了企業(yè)面臨的問(wèn)題。才能讓管理層、研發(fā)自身體會(huì)到好處。

我看了很多版本管理軟件的對(duì)比，無(wú)論是抬Svn打Git或者反之，我覺(jué)得都對(duì)也都不對(duì)。因?yàn)闊o(wú)論管理或者技術(shù)，本身沒(méi)有對(duì)錯(cuò)優(yōu)劣，問(wèn)題是場(chǎng)景。如果一個(gè)簡(jiǎn)單穩(wěn)定的后期維護(hù)項(xiàng)目，強(qiáng)推復(fù)雜的管理流程，效果不會(huì)好，因?yàn)闆](méi)有解決任何問(wèn)題，只會(huì)引入問(wèn)題。

管理的核心在于解決問(wèn)題，而不是管理行為本身。

1. 引用自 Trunk Based Development Introduction ?

2. 畫圖工具是使用gitgraphjs ?