背景

讓我們回到軟件開發(fā)的早期，那時有很多獨行的勇士，他們一個人寫一個操作系統(tǒng)、一個周末搞一個編輯器。他們把代碼上傳到FTP上，或通過磁盤分發(fā)。這個時期軟件開發(fā)由一兩個人獨自完成，不需要版本管理工具，也沒有分支模式。

隨著通用軟件和行業(yè)軟件的發(fā)展，軟件的規(guī)模越來越大，有些軟件需要幾千名工程師，經(jīng)過幾年的開發(fā)、測試，才能最終發(fā)布。大家比較熟悉的windows、office軟件等通信設(shè)備商開發(fā)的2G、3G基礎(chǔ)軟件是這方面的典型代表。隨著大型軟件開發(fā)的出現(xiàn)，版本管理工具隨之出現(xiàn)了，如CVS、Subversion和clearcase。這一階段通常是集中式的版本控制，分支比較昂貴，大家的提交頻率較低，代碼集成往往需要專門的配置管理工程師協(xié)助解決。軟件發(fā)布的周期從數(shù)周到數(shù)年。

之后軟件的應(yīng)用場景越來越廣，尤其是互聯(lián)網(wǎng)應(yīng)用的快速發(fā)展，要求軟件的發(fā)布周期越來越短。于是，微服務(wù)架構(gòu)被提了出來，單體應(yīng)用根據(jù)領(lǐng)域被拆分成多個服務(wù)，每個服務(wù)可以獨立開發(fā)、獨立測試、獨立部署。這樣，很多需求只需要涉及少數(shù)的幾個應(yīng)用，在十幾人以內(nèi)的小團(tuán)隊內(nèi)部就可以完成。互聯(lián)網(wǎng)應(yīng)用爆發(fā)，加上Git這樣的分布式版本管理工具出現(xiàn)，多分支開發(fā)變得普遍，高效的開發(fā)者經(jīng)常一天提交十幾次。軟件發(fā)布的周期縮短到數(shù)周乃至數(shù)天。

為什么要有分支模式

從前面的背景介紹，大家可能已經(jīng)發(fā)現(xiàn)，分支模式是隨著軟件協(xié)作的需求和版本管理工具的發(fā)展而產(chǎn)生的，它的出現(xiàn)，本質(zhì)上是為了解決兩個問題：1.沖突；2.返工。

通過避免沖突和減少返工，讓開發(fā)者關(guān)注在需求開發(fā)上，提升軟件的發(fā)布質(zhì)量和發(fā)布效率。

當(dāng)前，絕大多數(shù)軟件研發(fā)都采用Git為版本管理工具，為了簡單起見，之后我們提到分支模式，均特指基于Git的分支策略。

避免沖突

如果多個人同時在同一個應(yīng)用的同一個分支上開發(fā)，那么他們兩人的工作很容易產(chǎn)生沖突。這里的沖突不一定是Git提交時的conflict。像測試被其他人破壞，發(fā)布需要等待其他人完成，都屬于沖突的范疇。簡言之，一個需求的開發(fā)被其他需求開發(fā)活動所干擾，就產(chǎn)生了沖突。在Subversion時代，有些團(tuán)隊會采用定時排隊提交，驗證，回滾的策略，即到固定的時間點，按照協(xié)商的順序，每個人按順序提交自己的代碼，然后由配置管理員進(jìn)行構(gòu)建、測試，如果測試不通過，則提交被回滾。在這個期間，其他待提交人只能等待。于是乎，每次發(fā)布前，配置管理員都會異常辛苦。而由于提交不易，工程師傾向于一次提交更多的東西，但提交的改動越多，產(chǎn)生沖突的可能性也越大。

另外一種沖突，是合并的沖突，如主干上的某個增強補丁合并到發(fā)布過的一個分支上，由于代碼的基線不同，產(chǎn)生沖突，無法合并。

分支模式通過合理的開發(fā)、合并約定，來避免或減少上述沖突情況發(fā)生。

減少返工

由此可見，每一次返工的成本是很高的。

影響開發(fā)效率的另一個因素是返工。比如有些團(tuán)隊采用窗口制的發(fā)布策略，每周四是發(fā)布窗口。在這之前，很多功能都被提交到待發(fā)布分支上，如果此時針對待發(fā)布分支的測試發(fā)現(xiàn)某個功能有嚴(yán)重的問題，需要將該功能相關(guān)的提交從發(fā)布分支中去掉，不然就會影響其他功能的發(fā)布。那首先，得有人將該功能相關(guān)的提交都識別出來，進(jìn)行回滾，重新進(jìn)行構(gòu)建和測試；然后，該功能在問題修復(fù)后，需要再次提交，并且祈禱不再出現(xiàn)問題。

定義分支模式

那什么是分支模式，它又包含哪些內(nèi)容呢？分支模式的本質(zhì)是需求交付的流程和約束策略，它通常包括：

1、定義分支的類型及其標(biāo)識，通常包括：

• 需求開發(fā)分支

• 集成分支

• 待發(fā)布分支

• 發(fā)布分支

• 熱修復(fù)分支

2、分支的生命周期及創(chuàng)建消亡規(guī)則

3、提交在分支間的流轉(zhuǎn)規(guī)則和約束條件

4、發(fā)布與代碼的對應(yīng)關(guān)系，如Tag等方面。

如：某團(tuán)隊有20名開發(fā)，為企業(yè)客戶提供SaaS服務(wù)，定期發(fā)布版本。他們的分支模式如下：

1、存在四種分支：feature分支、develop分支、master分支和hotfix分支。

• feature-.*：需求開發(fā)分支

• develop：集成分支和待發(fā)布分支

• master：發(fā)布分支

• hotfix-.*：熱修復(fù)分支

2、develop和master為長期分支，feature-.*和hotfix-.*為臨時分支，開始開發(fā)時從develop創(chuàng)建，完成后合并入develop，分支消亡。

3、如：master不允許直接提交，必須從develop分支合并過來。

4、每次發(fā)布會在master上創(chuàng)建Tag，發(fā)布與Tag一一對應(yīng)。

怎么選擇分支模式

同時，如果有其他手段可以解決（如采用Feature Team減少跨團(tuán)隊協(xié)作），就不要用分支模式來解決。

在搜索引擎里搜索“分支模式”，大家可能會看到五花八門的各類分支模式，著名的如Git Flow、GitHub Flow、GitLab Flow和TBD（Trunk Based Development）等。怎么選擇呢？

原則

我的建議是根據(jù)團(tuán)隊和應(yīng)用的具體情況，按照：

?越簡單越好

?越自動越好

的原則來選擇。

方法

最后，一旦選擇了某個分支模式，就要保證切實執(zhí)行，并定期評審，確保現(xiàn)有分支模式符合當(dāng)前研發(fā)現(xiàn)狀需要。

具體落地的時候，分別考慮團(tuán)隊和應(yīng)用的特點。

對于團(tuán)隊，需要考慮的有：

• 團(tuán)隊數(shù)量

• 團(tuán)隊規(guī)模

• 團(tuán)隊內(nèi)協(xié)作需求

• 跨團(tuán)隊協(xié)作需求

• 團(tuán)隊技術(shù)偏好

對于應(yīng)用，需要考慮的有：

• 構(gòu)建依賴

• 運行依賴

• 發(fā)布依賴

• 單應(yīng)用規(guī)模

• 總應(yīng)用數(shù)

• 單次發(fā)布應(yīng)用數(shù)

然后根據(jù)開發(fā)->集成->驗證->發(fā)布的流程：

1. 從右往左來確定每個階段存在的沖突和協(xié)作需求

2. 判斷是否需要在該階段使用單獨的分支

3. 確定分支的進(jìn)入條件和生命周期。

有些團(tuán)隊在選擇分支模式時有個誤區(qū)，傾向于選擇看起來更專業(yè)的復(fù)雜分支模式。曾經(jīng)見過一個不到10人的團(tuán)隊卻選擇Git Flow這樣復(fù)雜的模式。事實上，以我的經(jīng)驗來說，我認(rèn)為現(xiàn)代互聯(lián)網(wǎng)軟件研發(fā)中，幾乎不需要用到Git Flow這樣的分支模式。筆者之前在10名研發(fā)規(guī)模的創(chuàng)業(yè)公司采用過類似下圖的只有一個分支的非常簡單的分支模式，在保證微服務(wù)拆分和自動化測試的前提下，效果很好。

最后，一旦選擇了某個分支模式，就要保證切實執(zhí)行，并定期評審，確保現(xiàn)有分支模式符合當(dāng)前研發(fā)現(xiàn)狀需要。

怎么落地分支模式

我們以為什么要有分支模式一章中的模式為例，結(jié)合云效2020，來看一下如何在云效Codeup中落地一個分支模式。

1、配置保護(hù)分支和合并條件

develop和master分支不允許開發(fā)者直接提交，我們需要將他們配置為保護(hù)分支。打開代碼庫的設(shè)置頁面，點擊分支設(shè)置，添加保護(hù)分支（以master分支為例）。

同時，配置合并的條件為：通過代碼評審和自動化檢查。

2、配置流水線模板

接下來，我們在云效流水線Flow中，為feature-.*、hotfix-.*、develop和master分支分別創(chuàng)建不同的流水線模板。他們是：

• 針對feature-.*分支的開發(fā)階段流水線*

• 針對hotfix-.*分支的緊急修復(fù)流水線

• 針對develop分支的集成階段流水線

• 針對master分支的發(fā)布階段流水線

3、應(yīng)用流水線模板

接下來就是在各個應(yīng)用中使用這些流水線模板了。對于不同的應(yīng)用類型（如Java應(yīng)用和Golang應(yīng)用），建議在階段上應(yīng)該是相同的，只是每個階段的具體內(nèi)容有所差別（如Maven單元測試和goconvey單元測試）。

至此，我們就可以在既定的分支模式的約定下進(jìn)行開發(fā)和發(fā)布了。

實踐建議

?單主干：一個代碼倉庫應(yīng)該保證有且僅有一個主干分支。

?最少長期分支：在避免沖突的前提下，盡量減少長期分支的數(shù)量

?Promotion：代碼的提交應(yīng)該是逐級合并，如feature->develop->master，避免feature->develop和feature->master同時存在

?發(fā)布不可變：發(fā)布的版本應(yīng)該是不可變且可回溯的

?自動化事件觸發(fā)：分支的持續(xù)集成過程應(yīng)該是自動化的，且通過提交事件或制品變更事件自動觸發(fā)。