技術(shù)永遠(yuǎn)是服務(wù)于業(yè)務(wù)，其實沒太大必要僅僅為了技術(shù)鍍金燎猛，而選擇高大上的方案恋捆。用最簡單的技術(shù)完成實際業(yè)務(wù)，四兩撥千斤重绷，才是王道沸停。

每種版本方案，都可以用每種工具來實現(xiàn)昭卓。比如git也能做Trunk Based愤钾，svn也能實現(xiàn)Git Flow，每個工具都有最適合使用的地方和時期候醒，沒什么高下之分绰垂。2014年在科匠產(chǎn)生過一次svn轉(zhuǎn)git的討論，最終沒轉(zhuǎn)，因為轉(zhuǎn)換之后并不能帶來價值。2018年在善為產(chǎn)生了一次svn轉(zhuǎn)git阻问，Trunk Based轉(zhuǎn)Git Flow的討論，最終都轉(zhuǎn)了占业，然后帶來了很多麻煩，有點得不償失的感覺纯赎。

1 Trunk Based

Trunk Based只有一個master主干谦疾，每個人都在本地寫新代碼，達(dá)到可提交程度的時候犬金，就往master合并念恍。如下圖：

關(guān)鍵點：

1. 這種模式在本地和 master 之間不存在一個緩沖的區(qū)域，所以從本地 commit 到 master 時晚顷，需要確保經(jīng)過了本地測試可用峰伙。

2. 過程足夠簡單，節(jié)省項目一致性成本该默。

3. 對項目或產(chǎn)品計劃要求不高瞳氓。有基本的WBS，任務(wù)計劃栓袖，里程碑計劃就行了匣摘。而且由于計劃復(fù)雜度要求不高，修改計劃的成本也就比較低裹刮。這點最本質(zhì)的說法音榜，就是產(chǎn)品只有一個 release線。

4. ABC三個模塊同時開發(fā)時捧弃，一旦決定只上線AB模塊赠叼，由于都在 master，線上版本其實也包含C模塊的部分塔橡。當(dāng)然可以也有辦法去回避這個問題梅割，比如 Feature Toggle，功能開關(guān)葛家。

最佳實踐：

1. 對項目和定義清晰的產(chǎn)品非常友好户辞。不適合走 IPD 過程而形成的 VRM 產(chǎn)品線IPD和VRM。不太適合探索型產(chǎn)品癞谒，原因是探索型產(chǎn)品可能需要做各種Feature底燎，最終有些留下有些不留，在TrunkBased模式下弹砚，沒有Feature分支双仍，剔除Feature不太方便。

2. 對持續(xù)集成桌吃，每日構(gòu)建朱沃，每日冒煙非常友好。

3. 為了減少本地代碼到 master 之間的時差，發(fā)揮持續(xù)集成和每日構(gòu)建的價值逗物，在項目計劃的WBS 時搬卒，任務(wù)顆粒應(yīng)該盡量小一些。因為顆粒越小翎卓，自測越迅速契邀，提交越快，沖突越小失暴。我們通常以人時為單位做 WBS坯门，原則上不允許一個任務(wù)超過8人時。通常在2到6左右逗扒。

2 Git Flow

Git Flow 在本地和 master 之間引入多個分支古戴，以做緩沖，集成和測試缴阎，保證 master 盡量干凈允瞧。在這個方案下，分為以下幾條分支：Master主分支蛮拔，Release發(fā)布分支述暂，Develop集成分支，Feature開發(fā)分支建炫，Hot Fixes線上bug分支畦韭。由于這個方案的復(fù)雜度較高，受到了很多批判肛跌，主要的點是說 long lived branch considered harmful 艺配。

主要過程如下：

2.1 初始環(huán)境。在 master 上打tag-0.1衍慎。

2.2 初始環(huán)境转唉。從 master 拉出 develop 分支。

2.3 開發(fā)新功能稳捆。在 develop 分支上拉出 feature 分支赠法，可能會有多個。

2.4 提交新功能乔夯。將完成單元測試的 feature 合并回 develop砖织。

2.5 集成測試。在 develop 上可能存在多個 feature 集成測試的 bug末荐，直接在 develop? 上改侧纯。

2.6 準(zhǔn)備發(fā)布。當(dāng)develop達(dá)到發(fā)布計劃的要求時甲脏，就從develop提交到release眶熬。

2.7 發(fā)布測試妹笆。在release上的bug，直接在release上改聋涨，改完merge回develop晾浴。

2.8 部署上線。從release提交到master牍白，并打上新tag-0.2，并從master部署上線抖棘。

2.9 線上bug茂腥。如果不是緊急bug，還是可以按常規(guī)feature去做切省。如果是緊急bug最岗，就從master拉出hotfixes，在hotfixes改和測朝捆，然后提交到master般渡，merge到develop。

關(guān)鍵點：

1. 引入了 Feature 分支芙盘。新特性完全在分支上開發(fā)驯用，避免了對 master 的污染，并且多個新特性同時開發(fā)儒老，不會相互影響蝴乔。

2. Feature 分支的長期存在，帶來很多麻煩驮樊。Feature 的顆粒薇正，需要反復(fù)考慮。如果顆粒較大囚衔，比如到模塊級挖腰，將導(dǎo)致 Feature 分支長期存在，帶來的問題就是合并時的大量沖突练湿，以及無法在 feature 完全完成前盡早集成猴仑。如果顆粒較小，又無法做到不污染主要分支鞠鲜。

3. 對項目或產(chǎn)品計劃要求較高 宁脊。產(chǎn)品計劃里要做好各個 Feature 的編號和管理，這樣才能更好的管理 develop 和 release 分支贤姆，使發(fā)布內(nèi)容和過程可視度更高榆苞。比如有時 Feature 即使做完了也暫時不提交到 Develop。

4. 持續(xù)集成的思路霞捡，在這個方案下是無效的坐漏。

5. 需要團隊的每個人，都理解每一個提交點合并點的意義。應(yīng)該從誰提交到誰赊琳，從誰 merge 到誰街夭。而團隊的能力總是分層的，總會有人不太理解躏筏，這時就會造成麻煩板丽。

最佳實踐：

1. 適合比較復(fù)雜的產(chǎn)品線。

2. 需要投入相對較大的成本維護各分支趁尼。也許需要有專人維護埃碱。

3. 需要配合維護比較完善的產(chǎn)品發(fā)布計劃。

總之酥泞，我覺得如果產(chǎn)品線復(fù)雜度比較高砚殿，也愿意花成本維護一套比較重的版本方案，Git Flow 還是比較規(guī)范的芝囤。

3 GitHub Flow

GitHub Flow 是對 Git Flow 的簡化：摒棄了紛繁復(fù)雜的多條分支似炎，只保留 Master 和 Feature 。并且建議 Feature 的顆粒在一個用戶故事上悯姊，故事完成時羡藐，就往 Master 合并。其實就是在解決long lived branch 引發(fā)的問題挠轴。過程如下：

4 Aone Flow

Aone Flow 采取了另外一個思路传睹。只存在一個 Master 分支，當(dāng)要開發(fā)時岸晦，就拉出新的 Feature 分支欧啤，可以同時存在多個 Feature，當(dāng)達(dá)到發(fā)布計劃時启上，就把需要合并的多條 Feature 分支合并起來邢隧，通過后再往 Master 上合并，并且tag下來冈在。