打开拉取请求后，审阅者会留下反馈，帮助你在代码合并前改进代码。 解决该反馈意味着了解每个批注，做出其要求所做的更改，并确保你已解决所有问题。
了解评审反馈
审阅者可以留下总体反馈，对特定行进行评论，并以建议的形式提出具体修改。 评审显示在拉取请求时间线中，以便你可以关注讨论，并查看哪些批注仍需要响应。 根据存储库设置，审阅者还可以批准你的拉取请求，或请求更改，要求你在合并之前先解决这些更改。
在更改任何内容之前，请阅读每个注释以了解其意图。 评论可能会指出某个缺陷、提出问题、要求换一种处理方式，或者建议你直接接受某项修改。
如果你有权访问 Copilot，它可以帮助你解释评论并提出修复，这在拉取请求有许多注释需要处理时很有用。
实现更改和修复代码
处理反馈时，可以：
- 直接应用审阅者建议的更改，这会将该建议提交到您的分支中。
- 在本地进行较大范围的修改，并将新的提交推送到该分支。
大多数反馈是通过更新代码并将新提交推送到拉取请求分支来解决的。 解决反馈时，将对话标记为已解决，以便你和你的审阅者都可以跟踪已完成的内容以及仍需要关注的内容。
当必需的审查者均已批准，且不再有任何待处理的修改请求时，拉取请求即可进入合并流程。 由于拉取请求与该分支关联，因此每次有新的提交时，都会更新拉取请求，并重新运行所有自动检查。
高效处理反馈
在更大或更严格的拉取请求上，一些做法可帮助你快速解决反馈问题：
- 通过将建议的更改添加到批次中来批量接受建议，这样多个已接受的更改就能合并到同一次提交中，而不是每条建议各自生成一次提交。
- 主动解决所有合并冲突，以便在拉取请求评审完成后快速完成合并。
- 在进行重大更改后，请重新请求评审，以便审阅者知道该拉取请求已可再次接受审查。
- 了解所需的审核。 当分支需要批准或代码所有者签字确认时，“请求更改”的评审或被撤销的批准都可能会阻止合并，直到问题得到解决。
- 通过创建一个链接回该评论的问题，而不是扩展拉取请求，来跟踪超出范围的反馈。
帮助你解决评论的工具
你不必独自手动逐条处理反馈：
-
在本地查看拉取请求 ，或在推送之前将其打开 GitHub Codespaces 以重现问题和测试修复。
-
解决审查期间提出的安全发现问题。 有关更改的代码扫描警报显示在拉取请求中，以便你可以在合并之前修复这些更改。
-
使用 Copilot 以解释反馈、回答问题、建议修复和解决与代理的合并冲突。