拉取请求支持将代码评审和合并到单个协作进程中。 开发人员添加功能或 bug 修复后，会创建拉取请求，开始将更改合并到上游分支的过程。 然后，其他团队成员有机会在完成代码之前对其进行评审和批准。 使用拉取请求评审正在进行的工作，及早获取更改反馈。 没有人承诺会合并这些更改。 所有者可以随时放弃拉取请求。
获取代码审查
作为合并请求的一部分进行的代码评审不仅仅是为了发现明显的bug，这就是测试的作用。 良好的代码评审可捕获不太明显的问题，这些问题可能导致以后出现成本高昂的问题。
代码评审有助于保护团队免受错误合并和生成失败，并且削弱团队生产力。 审查在合并之前发现问题，保护重要分支免受不必要的更改。
代码评审还鼓励和加强开发人员之间的协作和沟通。 团队获得了主分支和功能分支之间所做的所有更改的清晰历史记录。
在代码评审中，利用来自不同领域的审阅者，交流分享专业知识并推广解决问题的策略。 因为传播技能和知识使得团队更加强大且更有弹性。
提供出色的反馈
高质量评审从高质量反馈开始。 在拉取请求中获得出色反馈的关键包括：
- 让合适的人员审核合并请求。
- 确保审阅者知道代码的作用。
- 提供可作的建设性反馈。
- 及时回复批注。
在将审阅者分配到拉取请求的过程中，请务必选择正确的审阅者集合。 审阅者应该知道代码的工作原理，但也包括在其他领域的开发人员，以便他们可以分享他们的想法。
提供更改的明确说明，并提供包含修复或新功能的代码构建。 审阅者应努力提供有关他们不同意的更改的反馈。 确定问题，并提供关于可以采取哪些不同措施的具体建议。 此反馈具有明确的意图，并且很容易让拉取请求的所有者理解。
拉取请求所有者应回复批注、接受建议或解释他们拒绝应用它们的原因。 某些建议很好，但可能超出了拉取请求的范围。 请获取这些建议并创建新的工作项和功能分支，使其与拉取请求分开以进行更改。
使用策略保护分支
存储库中有一些关键分支，团队始终依赖这些分支处于良好状态，例如 main 分支。 团队可以要求使用拉取请求，以便在这些分支上进行任何更改，这可通过 GitHub 和 Azure DevOps 等平台实现。 将更改直接推送到受保护分支的开发人员将拒绝其推送。
添加其他条件以拉取请求，以在关键分支中强制实施更高级别的代码质量。 合并代码的彻底编译和多个审批者的批准是一些额外的要求，通常用于保护关键分支。
了解详细信息
GitHub 提供了关于如何使用拉取请求来建议对您工作的更改的详细文档。
详细了解 如何在代码评审中提供出色的反馈 ， 并使用拉取请求模板为审阅者提供指导。 Azure DevOps 还提供 丰富的拉取请求体验 ，可根据需要轻松使用和缩放。