Docs Library
处理 Review 反馈
PR 收到 review 反馈后如何正确处理：区分反馈类型、做出对应修改、安全地更新 PR，避免常见错误操作。
- 刚开始系统学 Git 的新手
- 想补齐最小协作闭环的人
- 会打开终端并进入仓库目录
- 知道本地和远端仓库的基本区别
- 跳过顺序直接学高风险命令
- 把示例命令直接用到当前工作仓库
引用与延伸阅读
- Git commit [官方]
- Git push [官方]
学完这篇你会掌握什么
- 区分 review 反馈的类型：必须修改、值得讨论、仅供参考
- 收到反馈后在本地正确修改并更新 PR
- 不触发不必要的 CI 重跑
- 理解 review 往返是协作的正常成本，不是冲突
先想一个问题
你刚发了一个 PR，满怀期待等着合并。结果 reviewer 回了 5 条评论——有要改的、有问问题的、有建议的。这时候你的第一反应是"又要改一遍"还是"先看一下每一条说的是什么"？
很多人收到 review 反馈后急着改代码，反而忽略了更重要的事：先理解 reviewer 在问什么。
收到 review 后的第一步：分类
review 反馈通常分三类：
- 必须修改——代码逻辑错误、安全隐患、缺少边界处理
- 值得讨论——设计选择、命名偏好、架构取舍
- 仅供参考——风格建议、非强制性优化
花 30 秒把评论大致分类，你就知道哪些要立刻改、哪些可以讨论、哪些可以直接说"了解了"。
如何修改并更新 PR
收到 review 后，不需要关闭 PR 重新开。直接在同一个分支上继续提交即可：
# 在同一个功能分支上
git switch feature/first-pr
# 根据反馈修改代码
git add <changed-files>
git commit -m "fix: handle edge case from review feedback"
# 推送到同一分支，PR 自动更新
git push origin feature/first-pr
PR 会自动添加新的提交，reviewer 可以看到你的修改。
几个重要的"不要"
- 不要 rebase 已推送的 PR 分支——除非你清楚知道自己在做什么。rebase 会改变提交哈希，reviewer 之前 review 过的提交就不见了
- 不要 force push 到 PR 分支——除非在 PR 开始前和 reviewer 沟通过
- 不要因为 review 往返次数多就觉得是自己写得差——review 本身就是协作的一部分
一旦 PR 收到了 review，force push 会让 reviewer 之前看过的代码消失。除非团队约定使用 squash merge，否则保持提交稳定。
给你的练习
- 在测试仓库中创建一个 PR，让同事给 2-3 条 review 意见，练习在同一个分支追加提交并更新 PR
- 故意在收到 review 后使用 rebase + force push，观察 review 页面发生什么
- 记录一个 PR 从发起到合并的 review 往返次数，分析哪一类反馈占多数
接下来建议继续学什么
pull request prep— 减少 review 往返的准备工作pull requests and reviews— PR 与代码审查最佳实践small batch review— 小批量 review 的优势
延伸阅读
沿着同一主题继续深入：