分支模式是我們在進行程式碼變更時的一種約定，它在版本管理工具（如Git）之上，約定我們在不同分支上的行為，達到提升開發協作效率的目的。雲效Codeup 是一款企業級程式碼管理平臺，提供程式碼託管、程式碼評審、程式碼掃描、質量檢測等功能，全方位保護企業程式碼資產，幫助企業實現安全、穩定、高效的研發管理。

背景

讓我們回到軟體開發的早期，那時有很多獨行的勇士，他們一個人寫一個作業系統、一個週末搞一個編輯器。他們把程式碼上傳到FTP上，或通過磁碟分發。這個時期軟體開發由一兩個人獨自完成，不需要版本管理工具，也沒有分支模式。 隨著通用軟體和行業軟體的發展，軟體的規模越來越大，有些軟體需要幾千名工程師，經過幾年的開發、測試，才能最終釋出。大家比較熟悉的windows、office軟體，華為等通訊裝置商開發的2G、3G基礎軟體是這方面的典型代表。隨著大型軟體開發的出現，版本管理工具隨之出現了，如CVS、Subversion和clearcase。這一階段通常是集中式的版本控制，分支比較昂貴，大家的提交頻率較低，程式碼整合往往需要專門的配置管理工程師協助解決。軟體釋出的週期從數週到數年。 之後軟體的應用場景越來越廣，尤其是網際網路應用的快速發展，要求軟體的釋出週期越來越短。於是，微服務架構被提了出來，單體應用根據領域被拆分成多個服務，每個服務可以獨立開發、獨立測試、獨立部署。這樣，很多需求只需要涉及少數的幾個應用，在十幾人以內的小團隊內部就可以完成。網際網路應用爆發，加上Git這樣的分散式版本管理工具出現，多分支開發變得普遍，高效的開發者經常一天提交十幾次。軟體釋出的的週期縮短到數週乃至數天。

為什麼要有分支模式

從前面的背景介紹，大家可能已經發現，分支模式是隨著軟體協作的需求和版本管理工具的發展而產生的，它的出現，本質上是為了解決兩個問題： 1.衝突 2.返工

通過避免衝突和減少返工，讓開發者關注在需求開發上，提升軟體的釋出質量和釋出效率。 當前，絕大多數軟體研發都採用Git為版本管理工具，為了簡單起見，之後我們提到分支模式，均特指基於Git的分支策略。 避免衝突 如果多個人同時在同一個應用的同一個分支上開發，那麼他們兩人的工作很容易產生衝突。這裡的衝突不一定是Git提交時的conflict。像測試被其他人破壞，釋出需要等待其他人完成，都屬於衝突的範疇。簡言之，一個需求的開發被其他需求開發活動所幹擾，就產生了衝突。在Subversion時代，有些團隊會採用定時排隊提交，驗證，回滾的策略，即到固定的時間點，按照協商的順序，每個人按順序提交自己的程式碼，然後由配置管理員進行構建、測試，如果測試不通過，則提交被回滾。在這個期間，其他待提交人只能等待。於是乎，每次釋出前，配置管理員都會異常辛苦。而由於提交不易，工程師傾向於一次提交更多的東西，但提交的改動越多，產生衝突的可能性也越大。 另外一種衝突，是合併的衝突，如主幹上的某個增強補丁合併到釋出過的一個分支上，由於程式碼的基線不同，產生衝突，無法合併。 分支模式通過合理的開發、合併約定，來避免或減少上述衝突情況發生。 減少返工 由此可見，每一次返工的成本是很高的。 影響開發效率的另一個因素是返工。比如有些團隊採用視窗制的釋出策略，每週四是釋出視窗。在這之前，很多功能都被提交到待發布分支上，如果此時針對待發布分支的測試發現某個功能有嚴重的問題，需要將該功能相關的提交從釋出分支中去掉，不然就會影響其他功能的釋出。那首先，得有人將該功能相關的提交都識別出來，進行回滾，重新進行構建和測試；然後，該功能在問題修復後，需要再次提交，並且祈禱不再出現問題。

定義分支模式

那什麼是分支模式，它又包含哪些內容呢？ 分支模式的本質是需求交付的流程和約束策略，它通常包括： 1、定義分支的型別及其標識，通常包括：

• 需求開發分支
• 整合分支
• 待發布分支
• 釋出分支
• 熱修復分支

2、分支的生命週期及建立消亡規則 3、提交在分支間的流轉規則和約束條件 4、釋出與程式碼的對應關係，如Tag 等方面。如：某團隊有20名開發，為企業客戶提供SaaS服務，定期釋出版本。他們的分支模式如下： 1、存在四種分支：feature分支、develop分支、master分支和hotfix分支

• feature-.*：需求開發分支
• develop：整合分支和待發布分支
• master：釋出分支
• hotfix-.*：熱修復分支

2、develop和master為長期分支，feature-.*和hotfix-.*為臨時分支，開始開發時從develop建立，完成後合併入develop，分支消亡 3、如：master不允許直接提交，必須從develop分支合併過來 4、每次釋出會在master上建立Tag，釋出與Tag一一對應

怎麼選擇分支模式

同時，如果有其他手段可以解決（如採用Feature Team減少跨團隊協作），就不要用分支模式來解決。 在搜尋引擎裡搜尋“分支模式”，大家可能會看到五花八門的各類分支模式，著名的如Git Flow、GitHub Flow、GitLab Flow和TBD（Trunk Based Development）等。怎麼選擇呢？ 原則 我的建議是根據團隊和應用的具體情況，按照： •越簡單越好 •越自動越好 的原則來選擇。 方法 最後，一旦選擇了某個分支模式，就要保證切實執行，並定期評審，確保現有分支模式符合當前研發現狀需要。 具體落地的時候，分別考慮團隊和應用的特點。 對於團隊，需要考慮的有：

• 團隊數量
• 團隊規模
• 團隊內協作需求
• 跨團隊協作需求
• 團隊技術偏好

對於應用，需要考慮的有：

• 構建依賴
• 執行依賴
• 釋出依賴
• 單應用規模
• 總應用數
• 單次釋出應用數

然後根據開發->整合->驗證->釋出的流程：

1. 從右往左來確定每個階段存在的衝突和協作需求
2. 判斷是否需要在該階段使用單獨的分支
3. 確定分支的進入條件和生命週期。

有些團隊在選擇分支模式時有個誤區，傾向於選擇看起來更專業的複雜分支模式。曾經見過一個不到10人的團隊卻選擇Git Flow這樣複雜的模式。事實上，以我的經驗來說，我認為現代網際網路軟體研發中，幾乎不需要用到Git Flow這樣的分支模式。筆者之前在10名研發規模的創業公司採用過類似下圖的只有一個分支的非常簡單的分支模式，在保證微服務拆分和自動化測試的前提下，效果很好。 最後，一旦選擇了某個分支模式，就要保證切實執行，並定期評審，確保現有分支模式符合當前研發現狀需要。

怎麼落地分支模式

我們以為什麼要有分支模式一章中的模式為例，結合雲效2020，來看一下怎麼落地一個分支模式。

說明 立即體驗：雲效分支模式

配置保護分支和合並條件 develop和master分支不允許開發者直接提交，我們需要將他們配置為保護分支。開啟程式碼庫的設定頁面，點選分支設定，新增保護分支（以master分支為例）。 同時，配置合併的條件為：通過程式碼評審和自動化檢查。 配置流水線模板 接下來，我們在雲效2020的企業模板中，為feature-.*、hotfix-.*、develop和master分支分別建立不同的流水線模板。他們是：

• 針對feature-.*分支的開發階段流水線*
• 針對hotfix-.*分支的緊急修復流水線
• 針對develop分支的整合階段流水線
• 針對master分支的釋出階段流水線

說明 立即體驗：雲效流水線Flow

應用流水線模板 接下來就是在各個應用中使用這些流水線模板了。對於不同的應用型別（如Java應用和golang應用），建議在階段上應該是相同的，只是每個階段的具體內容有所差別（如Maven單元測試和goconvey單元測試）。 至此，我們就可以在既定的分支模式的約定下進行開發和釋出了。

實踐建議

•單主幹：一個程式碼倉庫應該保證有且僅有一個主幹分支。

•最少長期分支：在避免衝突的前提下，儘量減少長期分支的數量

•Promotion：程式碼的提交應該是逐級合併，如feature->develop->master，避免feature->develop和feature->master同時存在

•釋出不可變：釋出的版本應該是不可變且可回溯的

•自動化事件觸發：分支的持續整合過程應該是自動化的，且通過提交事件或製品變更事件自動觸發。

通過雲效Codeup高效落地分支模式，提升開發協作率，分支模式通過避免衝突和減少返工，讓開發者關注在需求開發上，提升軟體的釋出質量和釋出效率。雲效Codeup是一款企業級程式碼管理平臺，提供程式碼託管、程式碼評審、程式碼掃描、質量檢測等功能，全方位保護企業程式碼資產，幫助企業實現安全、穩定、高效的研發管理。