---
tags: git, branch machanism
---
# git branch 模式

https://mp.weixin.qq.com/s/9Ey04P5Xv4W95N2FEioZ1g

## introduction

branch 的目的在於隔離

然而,每多一個分支(branch),代表要多維護一個分支情境

在這篇文章裡把,根據開發以及發布所在的特性，分為四種情況:

1 主幹開發 分支發布

2 主幹發布 分支開發

3 主幹開發 主幹發布

4 分支開發 分支發布

好的分支模式能有有效的增加 開發 集成 發布的效率

因此開發一個軟體專案時 選擇合適的分支模式 就是一個很重要的事情
## 設想情境：

Q1: 假設有一個軟體 只需要有一個版本 且只有一個開發者

適合哪一種分支模式？

Q2: 假設有一個軟體 需要因應各種國家法規 開設多個版本 且有多位開發者同時開發

適合哪一種分支模式?

## 主流的幾種分支模式

### 1 主幹開發模式(Trunk Base Development)

主幹開發 代表就是只有一個長期存在的開發branch 假設是 master

不允許其他開發分支長期存在

每次開發都要master 的source 來開發

開發驗證完立即merge 回 master

最後在從master merge 到 release branch

即使是要做bug修復 也是在 master修復

再cherry pick到 release branch


特點如下：

1 只有一個開發分支(master)

2 所有改動都發生在主幹分支

3 發布可以從主幹拉分支發布

4 主幹上進行的修复需要根据bug的修復策略，確定是否 cherry pick 到對應版本的發布分支。

***Notice***

為了讓主幹的代碼一直保持在可以work的狀態下，有幾個原則必須要遵守

1 每次的改動要盡量小 這樣驗證才能控制在某個範圍之內

2 要能夠快速的驗證，必須有完善的自動化驗證機制

3 因為團隊共享一個開發branch 因此每次commit都需要集成驗證

實際上開操作上 為了避免半成品影響整個 master branch

因此會需要在開發上使用feature Toggle的機制

然而 Feature Toggle類似於if else機制 一定程度會讓代碼變脆弱

Feature Toggle建立有良好的代碼架構上 才比較適合使用

### 2 git-flow

Git-flow 是為了解決多個feature並行開發所產生的分支模式

當要開發一個feature的時候 會先從主幹拉出一個feature branch

這時所有關於feature的改動都會在featrue branch

直到feature完成 才會從feature branch merge 回 develop branch

並且準備發布

Git-flow 會有以下幾種 branch:

1 feature branch: 為了開發某個feature 從 develop 分支出來的branch

2 release branch: 負責release版本的branch

3 develop branch: 負責集成所有feature branch 的branch, 未發布的最新feature branch

4 hotifx branch: 負責修復線上產品bug的branch

5 master branch: 保持最新已發布版本的 branch


開發feature flow:

1 接到開發需求 從develop 分支出 feature branch

2 完成本地開發驗證，commit到feature branch

3 基於feature branch 進行驗證並且持續合併新的commit

4 完成需求的開發 並且feature branch 驗證成功, merge feature branch to develop branch

5 在develop 進行集成驗證 完成驗證的feature branch會被刪除

6 在develop 驗證成功需要發布的feature, 從develop拉出release branch進行發布

7 發布release branch , merge release branch into develop and master branch, delete release branch

Hotfix flow:

1 發布之後，發現bug,從master拉出 hotfix branch

2 在hotfix 進行修正驗證

3 把問題修復merge到develop 跟 master

4 刪除hotfix

缺點:

1 分支特別多，每類分支都有特別用法

2 整個流程複雜需要團隊適度配合才能成功

3 feature branch如果太晚merge回 develop 將會造成 merge的解決conflict代價太高

4 develop branch的功能可以被master取代, 然而如果不需要develop ,那hotfix也可同樣是類似的概念

### 3 github flow

github flow 首先沒有所謂releaase branch

對於github flow來說 發布應該是持續進行 當一個版本準備好 就可以發布

而hotfix對於github flow來說也被當成某個feature branch

Github flow 流程如下：

1 master branch上的code都應該是最新可部屬能運行的版本

2 如果開發新的功能，從master拉出一個新的feature branch, branch name以工作任務命名

3 盡可能commit code該featrue branch

4 開完驗證完該feature branch, 對master branch 發起 pull request 申請code review

5 通過code reiew後,把feature branch deploy到test environment 進行驗證

6 驗證成功, code reviewer approve pull request到master並且deploy 到production environment


Github-flow鄉對於git-flow簡單

如果持續部屬 就能夠快速的發現master branch問題

並且有revert機制 快速復原

然而需要持續部屬 所以必須把deploy過程簡化自動化

### 4 gitlab flow

Gitlab-flow類似於Github-flow

把pull request代換成merge request同樣是作為code reivew的方式

最大差別在於引入 production, pre-production的branch

這兩個branch用來區隔 production環境跟 pre-production環境的code


Gitlab flow 流程如下：

1 master branch上的code都應該是最新可部屬能運行的版本

2 如果開發新的功能，從master拉出一個新的feature branch, branch name以工作任務命名

3 盡可能commit code該featrue branch

4 開完驗證完該feature branch, 對master branch 發起 merge request 申請code review

5 通過code reiew後,把feature branch deploy到test environment 進行驗證

6 驗證成功, code reviewer approve merge request到master並且deploy 到pre-production environment

7 pre-proudction運行成功 把pre-production merge到 production

## 優缺點分析

1 主幹開發模式 是主幹開發，可以是主幹發布也可以是分支發布

2 Git-Flow 是分支開發 分支發布

3 Github-Flow 是分支開發 主幹發布

4 Gitlab-Flow 分支開發,可以是主幹發布也可以是分支發布


## 選擇合適的模式

如果常見的這幾種分支模式都沒有符合團隊需求的

那也可以自己因應需求 設計出適合的flow給團隊使用