采用 Git 分支策略

Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019

通过分布式版本控制系统（如 Git），可以灵活地使用版本控制来共享和管理代码。 团队应在这种灵活性与以一致的方式进行协作和共享代码的需求之间找到平衡。

团队成员可以通过与他人共享的 Git 分支来发布、共享、评审和迭代代码更改。 为团队采用分支策略。 你可以更好地进行协作，花更少的时间管理版本控制，将更多时间用于开发代码。

以下分支策略基于我们在 Microsoft 使用 Git 的方式。 有关详细信息，请参阅如何在 Microsoft 使用 Git。

简化分支策略

简化分支策略。 基于以下三个概念生成策略：

• 将功能分支用于所有新功能和 bug 修复。
• 使用拉取请求将功能分支合并到主分支。
• 保持高质量、最新的主分支。

扩展这些概念并避免矛盾的策略可以为团队带来一致且易于遵循的版本控制工作流。

在工作中使用功能分支

根据主分支开发功能并修复功能分支中的 bug。 这些分支也称为主题分支。 功能分支将正在进行的工作与主分支中已完成的工作隔离开来。 Git 分支的创建和维护成本较低。 即使是较小的修复和更改也应有自己的功能分支。

为所有更改创建功能分支可以简化查看历史记录的过程。 查看在分支中进行的提交，并查看合并分支的拉取请求。

按约定命名功能分支

对功能分支使用一致的命名约定，以标识在分支中完成的工作。 还可以在分支名称中包含其他信息，例如分支的创建者。

有关命名功能分支的一些建议：

• 用户/用户名/说明
• 用户/用户名/工作项
• bug 修复/说明
• 功能/功能名称
• 功能/功能区域/功能名称
• 修补程序/说明

注意

有关设置策略以强制实施分支命名策略的信息，请参阅需要分支文件夹。

使用功能标志来管理长时间运行的分支

详细了解如何在代码中使用功能标志。

通过拉取请求评审和合并代码

在拉取请求中进行的评审对于提高代码质量至关重要。 仅凭可通过评审过程的拉取请求合并分支。 避免在没有拉取请求的情况下将分支合并到主分支。

拉取请求中的评审需要一段时间才能完成。 团队应就拉取请求创建者和评审者的期望达成一致。 分配评审者职责，以便在团队中分享想法，并传播代码库的知识。

成功拉取请求的一些建议：

• 研究显示，最好的配置是有两个评审者。
• 如果团队已有代码评审过程，请将拉取请求引入到你正在执行的操作中。
• 注意为大量拉取请求分配相同的评审者。 当在团队中共享评审者职责时，拉取请求效果更好。
• 在说明中提供足够详细的信息，使评审者快速处理你的更改。
• 在拉取请求中包括暂存环境中运行的更改的内部版本或链接版本。 其他人可以轻松测试更改。

保持高质量、最新的主分支

主分支中的代码可以通过测试、完全生成，并且始终保持最新。 主分支需要这样的质量，以便团队创建的功能分支可以从已知的良好代码版本开始。

为主分支设置分支策略，该策略：

• 需要拉取请求来合并代码。 此方法可防止直接推送到主分支，并确保对建议的更改进行讨论。
• 创建拉取请求时自动添加评审者。 添加的团队成员可评审代码并对拉取请求中的更改进行注释。
• 需要成功生成才能完成拉取请求。 合并到主分支中的代码应完全生成。

提示

拉取请求的生成管道应快速完成，这样就不会干扰评审过程。

管理版本

使用发布分支来协调和稳定代码版本中的更改。 此分支的生存期很长，不会在拉取请求中合并回主分支，这与功能分支不同。 根据需要创建任意数量的发布分支。 请记住，每个活动发布分支都表示需要支持的另一个代码版本。 准备好停止支持特定版本时，锁定发布分支。

使用发布分支

在接近发布或其他里程碑（如冲刺(sprint) 结束）时，从主分支创建发布分支。 为此分支指定一个与版本关联的明确名称，例如 release/20。

创建分支以修复发布分支中的 bug，并在拉取请求中将它们合并回发布分支。

将更改移植回主分支

确保修补程序同时位于发布分支和主分支中。 一种方法是在发布分支中进行修复，然后将更改引入主分支，以防止代码中出现回归。 另一种方法（也是 Azure DevOps 团队使用的方法）是始终在主线中进行更改，然后将这些更改移植到发布分支。 可以阅读有关发布流策略的详细信息。

在本主题中，我们将介绍如何在发布分支中进行更改并将其移植到主线中。 使用挑拣而不是合并，以便你可以精确地控制将哪些提交移植回主分支。 将发布分支合并到主分支中可能会产生你不希望在主分支中出现的特定于发布的更改。

执行以下步骤以使用在发布分支中进行的更改来更新主分支：

1. 在主分支外创建新的功能分支以移植更改。
2. 将更改从发布分支挑拣到新的功能分支。
3. 在第二个拉取请求中将功能分支合并回主分支。

此发布分支工作流使基本工作流的支柱保持不变：功能分支、拉取请求以及始终具有最新版本代码的强大主分支。

为什么不对发布使用标记？

其他分支工作流使用 Git 标记将特定提交标记为发布。 标记可用于将历史记录中的点标记为重要。 标记在工作流中引入了额外的步骤，如果对发布使用分支，则不需要执行这些步骤。

标记独立于提交进行维护和推送。 团队成员很容易错过标记提交，然后必须返回历史记录来修复标记。 你也可以忘记推送标记的额外步骤，让下一个开发人员在支持发布时使用旧版代码。

发布分支策略扩展了用于处理发布的基本功能分支工作流。 团队无需采用任何新的版本控制过程，但需要通过“挑拣”来移植更改。

管理部署

可以处理代码的多个部署，其方式与处理多个发布的方式相同。 创建明确的命名约定（例如 deploy/performance-test），并将环境分支视为发布分支。 团队应就使用主分支中的代码更新部署分支的过程达成一致。 将部署分支中的 bug 修复挑拣回主分支。 使用与从发布分支移植更改相同的步骤。

此建议的一个例外情况是，使用某种形式的持续部署。 使用持续部署时，请使用 Azure Pipelines 将生成从主分支提升到部署目标。