采用 Git 分支策略

Azure DevOps Services |Azure DevOps Server |Azure DevOps Server 2022 |Azure DevOps Server 2020

借助 Git 等分布式版本控制系统，你可以灵活地使用版本控制来共享和管理代码。 你的团队应该在这种灵活性与需要以一致的方式协作和共享代码之间找到平衡。

团队成员通过与他人共享的 Git 分支发布、共享、审阅和循环访问代码更改。 为团队采用分支策略。 可以更好地协作，减少管理版本控制的时间，以及开发代码的时间更多。

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

使分支策略保持简单

使分支策略保持简单。 基于以下三个概念构建策略：

• 对所有新功能和 bug 修复使用功能分支。
• 使用拉取请求将功能分支合并到主分支。
• 保持高质量的 up-to-date 主分支。

扩展这些概念并避免矛盾的策略将导致团队的版本控制工作流保持一致且易于遵循。

为工作使用功能分支

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

为所有更改创建功能分支使审阅历史记录变得简单。 查看分支中提交的提交，并查看合并分支的拉取请求。

按约定命名功能分支

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

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

• users/username/description
• users/username/workitem
• bugfix/description
• feature/feature-name
• feature/feature-area/feature-name
• 修补程序/说明

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

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

使用拉取请求查看和合并代码

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

拉取请求中的评审需要一段时间才能完成。 团队应就拉取请求创建者和审阅者的预期内容达成一致。 分发审阅者的职责，以在整个团队中分享想法，并分散对代码库的知识。

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

• 两位审阅者是基于 研究的最佳数字。
• 如果团队已有代码评审过程，请将拉取请求引入你已经在执行的作。
• 请小心将同一审阅者分配到大量拉取请求。 当审阅者职责在整个团队中共享时，拉取请求效果更好。
• 在说明中提供足够的详细信息，以便快速使审阅者快速完成更改。
• 使用拉取请求包括在分阶段环境中运行的更改的生成或链接版本。 其他人可以轻松测试更改。

保持高质量，up-to-date 主分支

主分支中的代码应通过测试、干净生成，并且始终为最新代码。 主分支需要这些品质，以便团队创建的功能分支从已知的良好代码版本开始。

为主 分支设置分支策略 ，以便：

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

管理版本

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

使用发布分支

当你接近发布或其他里程碑（例如冲刺结束）时，请从主分支创建发布分支。 为此分支指定一个明确名称，将其与发布相关联，例如 release/20。

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

端口更改回到主分支

确保修复位于发布分支和主分支中。 一种方法是在发布分支中进行修复，然后将更改引入主分支，以防止代码中的回归。 另一种方法（以及 Azure DevOps 团队使用的方法）是始终在主线进行更改，然后将这些更改移植到发布分支。 你可以详细了解我们的 发布流 策略。

在本主题中，我们将介绍如何在发布分支中进行更改，并将其移植到主线。 使用切入选取，而不是合并，以便可以完全控制将提交移植回主分支。 将发布分支合并到主分支可以引入主分支中不需要的特定于发布的更改。

使用在发布分支中所做的更改更新主分支，并按照以下步骤作：

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

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

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

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

标记与提交分开进行维护和推送。 团队成员可以轻松错过标记提交，然后必须返回历史记录以修复标记。 还可以忘记推送标记的额外步骤，让下一个开发人员在支持发布时从旧版本的代码中工作。

发布分支策略扩展了用于处理发布的基本功能分支工作流。 你的团队无需采用任何新版本控制过程，而不是切选来移植更改。

管理部署

可以采用处理多个版本的相同方式处理代码的多个部署。 创建明确的命名约定，例如 部署/性能测试，并像发布分支一样处理环境分支。 团队应同意使用主分支中的代码更新部署分支的过程。 部署分支中的切入 bug 修复回到主分支。 使用与从发布分支移植更改相同的步骤。

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