通过拉取请求获取反馈

拉取请求支持查看代码并将其合并到单个协作流程中。开发人员添加功能或 bug 修复程序后便会创建拉取请求，从而开始将更改合并到上游分支。然后，其他团队成员有机会在完成代码之前对其进行评审和批准。使用拉取请求评审正在进行的工作，及早获取更改反馈。但是，不会承诺合并更改。负责人可随时放弃拉取请求。

评审代码

在拉取请求中完成的代码评审并非只是为了找到明显 bug，这是测试的主要目的。适当的代码评审可捕获不太明显的问题，这些问题可能会导致后续产生巨大成本。

代码评审可帮助保护团队免受不良合并和中断生成的影响，这些都会削弱团队的生产力。评审可在合并之前捕获问题，从而避免重要分支进行不必要的更改。

代码评审还可鼓励和加强开发人员之间的协作和沟通。同时，团队还可获取主分支和功能分支之间所做全部更改的清晰历史记录。

通过在代码评审中使用不同评审者，交叉传播专业知识并传播解决问题的策略。传播的技能和知识可让团队更为强大且更具弹性。

高质量评审从高质量反馈开始。拉取请求中优秀反馈的关键是：

向拉取请求分配评审者时，请务必选择正确的评审者群体。评审者应了解代码的工作原理，同时还应包括从事其他领域的开发人员，以便他们可以分享自己的想法。

提供更改的明确说明，同时提供具有有效修复或功能的代码构建。评审者应努力对其不同意的更改提供反馈。确定问题并就可采取的不同做法提出具体建议。此反馈有明确的意图，便于拉取请求的所有者了解。

拉取请求负责人应回复注释、接受建议或解释拒绝应用它们的原因。某些建议很好，但可能超出了拉取请求的范围。根据这些建议，在拉取请求之外创建新的工作项和功能分支，以进行这些更改。

存储库中有几个关键分支，且团队依赖它们始终处于良好状态，例如 main 分支。团队可能需要拉取请求，以便使用平台（如 GitHub 和 Azure DevOps）对这些分支进行所有更改。对于直接向受保护的分支推送更改的开发人员，他们的推送将被拒绝。

向拉取请求添加其他条件，以便在关键分支中强制要求更高水平的代码质量。为保护关键分支而采用的部分额外要求包括：对合并后的代码创建干净构建，以及由多名评审者进行批准。

GitHub 提供了有关如何通过拉取请求提出工作更改的丰富文档。