什么是分支模式

Flow對分支模式提供了強有力的支持：用戶可以只需要關心集成和發布哪些 feature 分支，而對 release 分支創建和管理、分支合并等一系列工作，可以托付給 Flow 完成。

本節內容詳細介紹分支模式下，各（類）分支的使用方式。

master 代表最新發布版本

一般情況下， master 分支代表最新發布版本。當需要最新發布版本的內容時，直接取分支末端即可。

不論其他哪類分支，都建議一般從 master 分支創建，并且經常從 master 分支合并，以便跟上“潮流”，減少將來集成時的各種問題，比如代碼合并沖突。

每當軟件正式發布前，系統會確保它基于 master 最新。

在各 feature 分支上開發

一條 feature 分支（又稱變更分支、開發分支），通常用來承載一個缺陷的修復，或者一個需求（如果不是很大的話）的開發，或者任務分解后一個任務的開發。

一般來講，基于 master 分支最新版本創建 feature 分支。然后在 feature 分支上開發、測試，直到這個 feature 功能完成，質量 OK，準備好去集成和發布。

release 分支上的集成

release 分支用于集成和發布。基于 master 分支最新版本創建一條 release 分支，然后把想要集成的各條feature分支合并到這條release分支，進行部署和測試工作。

如果有新的 feature 分支要加入本次集成，那就把它也合并進這條 release 分支，然后再次部署并測試。

如果測試發現問題，就到 feature 分支上修復，然后把它再次合并到 release 分支，把修復帶到 release 分支。

當然如果一個 feature 的問題太多太大，那干脆就放棄它。也就是說，新建一條 release 分支，把其他 feature 分支都合并過去，唯獨不再合并這條 feature 分支。

就像 master 分支一樣，release 分支也是由系統自動管理的。使用者不要直接在上面改代碼，代碼修改請總是在 feature 分支完成。

release 分支上的發布上線

當 release 分支上的質量足夠好，本次想上線的功能也都具備之后，就要考慮發布上線的問題啦。如前面講的，發布上線前，會確保它基于基礎分支（常見的如 master ）最新。而發布后會把 release 分支合并回 master，讓 master 代表最新發布版本。

以上幾節介紹的內容，見下圖：

多個環境/流程時

假定要想集成發布上線，要經過日常測試環境上的測試這個流程，還要經過預發環境上的測試這個流程，那么兩個流程用一條 release 分支就有些不合適。因為兩個流程可能同時在測不同的 feature 分支集合。

分支模式用這個辦法避免這個問題：每一個測試環境，也就是每個流程，關聯它自己的 release 分支。日常測試、預發測試這兩個環境（也就是兩個流程），分別關聯兩條 release 分支。這樣就不會相互影響。推而廣之，為正式運行環境，也對應一條release分支。也就是說，每個環境都有對應的 release 分支。

當把集成成果從一個環境傳遞到下一個環境時，就是把一個環境下已合并到一起的 feature 分支，再往另一個環境對應的 release 分支上合并一遍……這么做有點兒笨。系統實際的做法是，基于 master 分支創建另一個環境對應的 release 分支，然后把前一個環境對應的 release 分支合并到新的 release 分支上。

本節介紹的內容，對應下圖：

以上就是關于分支模式這種研發模式的原理性介紹，以下我們看一下如何在流水線中使用分支模式。

如何在流水線中使用分支模式

編排流水線

流水線的新建方式其他流水線相同，當新建流水線時選擇了「開啟分支模式」，就會自動創建包含【分支管理器】的分支模式流水線。

1. 新建流水線

2. 添加代碼源，以使用「云效Codeup」為例，選擇代碼庫，選擇「開啟分支模式」，然后點擊「添加」

   

3. 添加完成后，在「流程配置」頁面可以看到第一個階段「分支管理器」。在分支管理器中設置基礎分支，基礎分支默認是 master。基礎分支是發布分支的創建來源。發布分支從基礎分支創建，然后合并運行分支。「分支管理器」只能是在第一個階段配置，且在這個階段不能配置并行任務。