重新请求评审是什么
重新请求评审（re-request review）是提交修改后主动发出的一个明确信号：告诉评审人「新版本已经就绪，请再看一遍」。评审平台通常会把评审人的状态从「已评审」重置回「待评审」，并给他一条通知。没有这个动作，评审人只能靠猜——不知道你是还在改，还是已经改完了。
基本信息
| 适用平台 | GitHub、GitLab 均有等价操作 |
|---|---|
| 触发时机 | 评审意见处理完、新一轮提交已推送之后 |
| GitHub 入口 | 评审人列表旁的循环箭头按钮 |
| GitLab 入口 | 重新指派评审人，或在讨论中留言说明已处理 |
| 命令行辅助 | gh pr view <编号> --json reviewRequests,reviewDecision |
典型使用场景
- 一轮评审意见全部处理完毕，需要对方复核而不是反复口头催问
- 只处理了部分意见，明确说明哪些已改、哪些不改以及原因
- 长周期 PR 多次迭代，每轮推送后都希望重置「等待复核」状态
- 团队统计评审时效时，重新请求是这一轮计时的起点
- 改动范围较大时附上本轮变更摘要，降低对方复读成本
配套动作
配套动作
git push origin feature/login # 推送本轮修改
git status # 确认没有漏提交的文件
git diff --stat origin/main...HEAD # 汇总本 PR 相对主干改动面
git log --oneline origin/main..HEAD # 列出本 PR 的提交清单
gh pr view 128 --json reviewRequests,reviewDecision # 查看当前评审请求与结论什么时候重新请求
| 情况 | 做法 | 原因 |
|---|---|---|
| 意见全部处理完 | 重新请求评审 | 明确告知存在新版本 |
| 只处理一部分 | 重新请求并留言说明 | 让对方知道剩余项的结论 |
| 纯文字回复无代码改动 | 评论回复即可 | 没有新版本可看 |
| 仅重排提交或合并主干 | 按团队约定处理 | 多数情况下无需重置评审状态 |
回复每条评论时写明「已改」或「不改的原因」并链接到对应提交，对方复核成本更低，也留下决策记录。对不接受的意见同样要给出理由，而不是沉默地跳过。
多轮修改时避免一次推送上千行：把无关的格式化改动拆到独立提交或独立 PR，重新评审才真的会变快。反复重置状态却不回应具体意见，会被视为刷状态而非推进。