本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

# Gitflow 分支策略
<a name="gitflow-branching-strategy"></a>

Gitflow 是一種分支模型，涉及使用多個分支將程式碼從開發移至生產環境。Gitflow 非常適合具有排程發行週期且需要將功能集合定義為發行版本的團隊。開發會在個別特徵分支中完成，這些分支在獲得核准的情況下合併到用於整合的開發分支中。此分支中的功能視為已準備好進行生產。當開發分支中累積所有計劃的功能時，就會建立發行分支以部署到上層環境。此區隔可改善對依定義排程將哪些變更移至哪個具名環境的控制。如有必要，您可以將此程序加速為更快的部署模型。

如需 Gitflow 分支策略的詳細資訊，請參閱下列資源：
+ [實作多帳戶 DevOps 環境的 Gitflow 分支策略](https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/implement-a-gitflow-branching-strategy-for-multi-account-devops-environments.html) (AWS 方案指引）
+ [原始 Gitflow 部落格 ](https://nvie.com/posts/a-successful-git-branching-model/)(Vincent Driessen 部落格文章）
+ [Gitflow 工作流程](https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow) (Atlassian)

**Topics**
+ [Gitflow 策略的視覺化概觀](visual-overview-of-the-gitflow-strategy.md)
+ [Gitflow 策略中的分支](branches-in-a-gitflow-strategy.md)
+ [Gitflow 策略的優點和缺點](advantages-and-disadvantages-of-the-gitflow-strategy.md)

# Gitflow 策略的視覺化概觀
<a name="visual-overview-of-the-gitflow-strategy"></a>

下圖可以像 [Punnett 方形](https://en.wikipedia.org/wiki/Punnett_square)一樣使用，以了解 Gitflow 分支策略。將垂直軸上的分支與水平軸上的 AWS 環境對齊，以決定在每個案例中要執行的動作。圓圈數字會引導您完成圖表中所呈現的動作順序。如需每個環境中發生之活動的詳細資訊，請參閱本指南中的 [DevOps 環境](understanding-the-devops-environments.md)。



![\[每個分支和環境中 Gitflow 活動的 Punnett 平方\]](http://docs.aws.amazon.com/zh_tw/prescriptive-guidance/latest/choosing-git-branch-approach/images/gitflow-diagram.png)


# Gitflow 策略中的分支
<a name="branches-in-a-gitflow-strategy"></a>

Gitflow 分支策略通常具有下列分支。



![\[Gitflow 分支策略中的分支和環境。\]](http://docs.aws.amazon.com/zh_tw/prescriptive-guidance/latest/choosing-git-branch-approach/images/gitflow-branching-strategy.png)


## 功能分支
<a name="feature-branch"></a>

`Feature` 分支是您開發功能的短期分支。`feature` 分支是透過分支離開`develop`分支來建立的。開發人員在`feature`分支中反覆執行、遞交和測試程式碼。功能完成後，開發人員會提升此功能。只有兩個路徑從特徵分支轉送：
+ 合併至`sandbox`分支
+ 在`develop`分支中建立合併請求


|  |  | 
| --- |--- |
| 命名慣例： | `feature/<story number>_<developer initials>_<descriptor>` | 
| 命名慣例範例： | `feature/123456_MS_Implement_Feature_A` | 

## 沙盒分支
<a name="sandbox-branch"></a>

`sandbox` 分支是 Gitflow 的非標準短期分支。不過，它適用於 CI/CD 管道開發。`sandbox` 分支主要用於下列目的：
+ 使用 CI/CD 管道而非手動部署來執行沙盒環境的完整部署。
+ 在較低環境中提交合併請求進行完整測試之前，開發和測試管道，例如開發或測試。

`Sandbox` 分支本質上是暫時的，並不意味著長期存在。應該在特定測試完成後將其刪除。


|  |  | 
| --- |--- |
| 命名慣例： | `sandbox/<story number>_<developer initials>_<descriptor>` | 
| 命名慣例範例： | `sandbox/123456_MS_Test_Pipeline_Deploy` | 

## 開發分支
<a name="develop-branch"></a>

`develop` 分支是長期分支，可將功能整合、建置、驗證和部署到開發環境。所有`feature`分支都會合併到`develop`分支中。合併至`develop`分支是透過需要成功建置和兩個開發人員核准的合併請求完成。若要防止刪除，請在分支上啟用`develop`分支保護。


|  |  | 
| --- |--- |
| 命名慣例： | `develop` | 

## 發行分支
<a name="release-branch"></a>

在 Gitflow 中，`release`分支是短期分支。這些分支很特別，因為您可以將它們部署到多個環境，採用建置一次、部署許多方法。 `Release`分支可以鎖定測試、預備或生產環境。在開發團隊決定將功能提升到更高的環境之後，他們會建立新的`release`分支，並使用先前版本的版本編號遞增。在每個環境的閘道上，部署需要手動核准才能繼續。 `Release`分支應該需要變更合併請求。

在`release`分支部署到生產環境之後，應該將其合併回 `develop`和 `main`分支，以確保任何錯誤修正或 Hotfix 都合併回未來的開發工作。


|  |  | 
| --- |--- |
| 命名慣例： | `release/v{major}.{minor}` | 
| 命名慣例範例： | `release/v1.0` | 

## 主要分支
<a name="main-branch"></a>

`main` 分支是長期分支，一律代表在生產環境中執行的程式碼。從發行管道成功部署後，程式碼`main`會自動從發行分支合併到分支。若要防止刪除，請在分支上啟用`main`分支保護。


|  |  | 
| --- |--- |
| 命名慣例： | `main` | 

## bugfix 分支
<a name="bugfix-branch"></a>

`bugfix` 分支是短期分支，用於修正尚未發佈至生產環境的發行分支中的問題。`bugfix` 分支應僅用於將`release`分支中的修正提升為測試、預備或生產環境。`bugfix` 分支一律從`release`分支分支分支。

測試錯誤修正之後，可以透過合併請求將其提升為`release`分支。然後，您可以遵循標準發行程序，將`release`分支向前推。


|  |  | 
| --- |--- |
| 命名慣例： | `bugfix/<ticket>_<developer initials>_<descriptor>` | 
| 命名慣例範例： | `bugfix/123456_MS_Fix_Problem_A` | 

## hotfix 分支
<a name="hotfix-branch"></a>

`hotfix` 分支是用於修正生產中問題的短期分支。它僅用於提升必須加速才能到達生產環境的修正。`hotfix` 分支一律從 分支`main`。

測試 Hotfix 之後，您可以透過將請求合併到從 建立的`release`分支，將其提升至生產環境`main`。然後，您可以遵循標準發行程序，將`release`分支向前推送以進行測試。


|  |  | 
| --- |--- |
| 命名慣例： | `hotfix/<ticket>_<developer initials>_<descriptor>` | 
| 命名慣例範例： | `hotfix/123456_MS_Fix_Problem_A` | 

# Gitflow 策略的優點和缺點
<a name="advantages-and-disadvantages-of-the-gitflow-strategy"></a>

Gitflow 分支策略非常適合具有嚴格發行和合規要求的更大、更分散的團隊。Gitflow 為組織的可預測發行週期做出貢獻，而較大的組織通常偏好這樣做。Gitflow 也非常適合需要護欄才能正確完成其軟體開發生命週期的團隊。這是因為策略中有許多檢閱和品質保證的機會。Gitflow 也非常適合必須同時維護多個生產版本的團隊。GItflow 的某些缺點是它比其他分支模型更複雜，並且需要嚴格遵守模式才能成功完成。由於管理發行分支的剛性，Gitflow 不適用於努力持續交付的組織。Gitflow 發行分支可以是長期分支，如果未及時正確解決，可能會累積技術債務。

## 優點
<a name="advantages"></a>

以 Gitflow 為基礎的開發提供多種優勢，可以改善開發程序、簡化協同合作，並增強軟體的整體品質。以下是一些主要優點：
+ **可預測發行程序** – Gitflow 遵循一般且可預測的發行程序。它非常適合具有定期開發和發行節奏的團隊。
+ **改善協同合作** – Gitflow 鼓勵使用 `feature`和 `release`分支。這兩個分支可協助團隊以最小的相依性並行運作。
+ **非常適合多個環境** – Gitflow 使用`release`分支，這可能是更長的分支。這些分支可讓團隊鎖定較長時間內的個別版本。
+ **生產中的多個版本** – 如果您的團隊在生產環境中支援多個版本的軟體，則 Gitflow `release`分支支援此要求。
+ **內建程式碼品質審查** – Gitflow 要求並鼓勵在程式碼提升到另一個環境之前使用程式碼審查和核准。此程序要求所有程式碼提升執行此步驟，以消除開發人員之間的摩擦。
+ **組織優勢** – Gitflow 在組織層級也有優勢。Gitflow 鼓勵使用標準發行週期，這有助於組織了解和預測發行排程。由於企業現在了解何時可以交付新功能，因此由於有設定交付日期，因此時間軸的摩擦會減少。

## 缺點
<a name="disadvantages"></a>

Gitflow 型開發確實有一些缺點，可能會影響開發程序和團隊動態。以下是幾個顯著的缺點：
+ **複雜性** – Gitflow 是新團隊學習的複雜模式，您必須遵守 Gitflow 的規則才能成功使用。
+ **持續部署** – Gitflow 不適用於許多部署以快速方式發佈至生產環境的模型。這是因為 Gitflow 需要使用多個分支和管理`release`分支的嚴格工作流程。
+ **分支管理** – Gitflow 使用許多分支，這可能會變得難以維護。追蹤各種分支並合併發行的程式碼，以便讓分支彼此正確對齊，可能具有挑戰性。
+ **技術負債** – 由於 Gitflow 發行速度通常比其他分支模型慢，因此有更多功能可以累積發行，這可能會導致技術負債累積。

團隊在決定 Gitflow 型開發是否為適合其專案的正確方法時，應仔細考慮這些缺點。