通过

关于拉取请求

  • 项目

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

拉取请求 (PR) 是一种用于在 Azure Repos 上的 Git 存储库中更改、评审和合并代码的方法。 PR 可以来自同一存储库中的分支，也可以来自存储库分支中的分支。 在将代码合并到主分支之前，团队使用 PR 评审代码并提供更改反馈。 审阅者可以逐步执行建议的更改、留下注释，并投票批准或拒绝代码。

本文介绍拉取请求准则和管理注意事项。 有关如何创建、查看、评审和完成拉取请求的说明，请参阅以下文章：

注意

出于性能和稳定性原因，可添加到拉取请求的审阅者人数必须为 1000 或更少。 添加超过 1000 名审阅者时不会创建新的拉取请求，现有拉取请求不允许添加超过 1000 名审阅者。

权限和先决条件

  • 必须在项目上启用 Repos。 如果 Repos 中心和关联页面未显示，请参阅打开或关闭 Azure DevOps 服务以重新启用 Repos。

  • 若要查看或评审 PR，必须是 Azure DevOps 项目的成员，具有基本访问级别或更高级别。

  • 若要参与 PR，必须是“读取者”安全组的成员或具有相应的权限。

  • 若要创建和完成 PR，必须是“参与者”安全组的成员或具有相应的权限。

注意

对于公共项目，被授予利益干系人访问权限的用户对 Azure Repos 具有完全访问权限。

  • 必须在项目上启用 Repos。 如果 Repos 中心和关联页面未显示，请参阅打开或关闭 Azure DevOps 服务以重新启用 Repos。
  • 若要查看或评审 PR，必须是 Azure DevOps 项目的成员，具有基本访问级别或更高级别。 如果你不是项目成员，请添加为成员。
  • 若要参与 PR，必须是“读取者”安全组的成员或具有相应的权限。
  • 若要创建和完成 PR，必须是“参与者”安全组的成员或具有相应的权限。

有关权限和访问权限的详细信息，请参阅 默认 Git 存储库和分支权限 以及 关于访问级别。

拉取请求的质量反馈

高质量评审从高质量反馈开始。 良好的 PR 反馈有以下几个要点：

  • PR 所有者应让合适的人员评审 PR，并确保审阅者知道代码的作用。
  • 审阅者应提供可操作的建设性反馈。
  • 所有者和审阅者应留下注释并快速答复。

PR 所有者应：

  • 确保选择合适的审阅者来分配给 PR。
  • 纳入了解代码工作原理的审阅者。
  • 让处理其他领域的开发人员分享其想法。
  • 提供清晰的更改说明。
  • 使用拉取请求模板提供审阅者指南。
  • 提供一个代码版本，其中在运行修补程序或功能。
  • 回复注释，接受建议或解释为何建议的更改不合适。
  • 对于 PR 范围之外的好建议，请创建新的工作项、分支和 PR 以进行这些更改。

审阅者应执行以下任务。

  • 对他们不同意的更改提供反馈
  • 找出问题所在，并就如何采取不同的措施给出具体建议
  • 确保反馈意图明确且易于理解
  • 对更改留下评论或投票

有关详细信息，请参阅获取 Git 拉取请求的反馈。

分支策略和拉取请求

你的团队可能依赖于存储库中的关键分支（例如 main 分支）来保持良好的状态。 可将分支策略设置为要求对这些受保护分支上的任何更改使用 PR，并拒绝直接推送到分支的任何更改。

可以将更多策略添加到 PR，以在关键分支中实现更好的代码质量。 额外的要求（例如建议代码的干净生成或得到多个审阅者的批准）可以帮助保护关键分支。

可以在分支策略中设置 PR 所需的审批数。 还可将所有或某些 PR 上的某些审阅者设置为必需或可选。 可以将 PR 设置为即使其他审阅者拒绝更改，也可在获得所需的审批数时自动完成。 但是，所需的审阅者必须先批准 PR，然后才能合并 PR。 最佳做法是至少让两名审阅者审查和批准重要 PR 中的更改。

若要在 PR 作者推送新更改时重置投票，请在需要最少数量的审阅者分支策略中选择“有新更改时重置代码审阅者投票”。

下表汇总了可定义的策略，可使用这些策略自定义分支。 有关所有存储库以及分支策略和设置的概述，请参阅 Git 存储库设置和策略。

策略

默认值

说明

需要最少数量的审阅者

关

需要拉取请求获得指定数量的审阅者的批准。

检查链接的工作项

关

通过检查拉取请求的链接工作项来提高可跟踪性

检查注释解决情况

关

检查是否已解决拉取请求的所有注释。

限制合并类型

关

通过在拉取请求完成时限制可用的合并类型，可以控制分支历史记录。

添加生成验证策略

关

添加一个或多个策略以通过预合并和生成拉取请求更改来验证代码。 也可启用或禁用策略。

添加状态检查策略

关

添加一个或多个策略以要求其他服务发布成功状态才能完成拉取请求。 也可启用或禁用策略。

自动包含的审阅者

关

添加一个或多个策略以指定在拉取请求更改特定代码区域时自动包含的代码审阅者。 也可启用或禁用策略。

有关详细信息，请参阅：

定义状态检查以提高代码质量

拉取请求和分支策略使团队可以强制执行关于评审代码和运行自动化生成的最佳做法。 许多团队对代码有进一步的需求和验证。 若要满足这些需求，可将 PR 状态检查集成到 PR 工作流中。 借助 PR 状态检查，外部服务可通过将成功或失败信息与 PR 相关联来以编程方式对代码更改进行签名。

有关详细信息，请参阅以下文章：

多个合并基本问题

在某些情况下，一个 PR 有多个真正的合并库，这种情况可能会导致安全问题。 如果 PR 中的文件在合并库之间具有不同的版本，则会出现多个合并库警告。 有关详细信息和修正方法，请参阅多个合并库。

后续步骤