本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。

# 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_cn/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_cn/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`分支，以确保将任何错误修复或修补程序合并回未来的开发工作中。


|  |  | 
| --- |--- |
| 命名惯例： | `release/v{major}.{minor}` | 
| 命名约定示例： | `release/v1.0` | 

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

该`main`分支是一个长期存在的分支，它始终代表生产中运行的代码。从发布管道成功部署后，代码将自动从发布分支合并到分支中。`main`为防止删除，请在分支上启用`main`分支保护。


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

## 错误修复分支
<a name="bugfix-branch"></a>

该`bugfix`分支是一个短期分支，用于修复尚未发布到生产环境的发布分支中的问题。分`bugfix`支只能用于将分`release`支中的修复提升到测试、暂存或生产环境。分`bugfix`支总是从分支上分`release`支。

测试错误修正后，可以通过合并请求将其提升到`release`分支。然后，您可以按照标准发布流程推动`release`分支向前发展。


|  |  | 
| --- |--- |
| 命名惯例： | `bugfix/<ticket>_<developer initials>_<descriptor>` | 
| 命名约定示例： | `bugfix/123456_MS_Fix_Problem_A` | 

## 修补程序分支
<a name="hotfix-branch"></a>

该`hotfix`分支是一个短期分支，用于修复生产中的问题。它仅用于推广必须加快才能进入生产环境的修复程序。分`hotfix`支总是从中分支。`main`

测试完此修补程序后，您可以通过向从`main`中创建的`release`分支发出合并请求，将其提升到生产环境。为了进行测试，您可以按照标准发布流程将`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 的开发是否是其项目的正确方法时，应仔细考虑这些缺点。