

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

# 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` | 