三种评审动作是什么
GitHub 提交评审时要在三种动作里选一个：Comment（只留评论不表态）、Approve（批准）、Request changes（请求修改）。前两者不阻止合并（除非分支保护另有要求），请求修改默认会阻止合并，直到作者修改并收到复核。动作选错，要么让改动卡住，要么让风险直接溜过去。
基本信息
| 适用平台 | GitHub PR 评审；GitLab MR 有对应的批准与请求修改机制 |
|---|---|
| 三种动作 | Comment / Approve / Request changes |
| 阻塞语义 | 只有 Request changes 默认阻止合并，需复核后解除 |
| 计数规则 | Approve 计入分支保护要求的批准数，Comment 不计入 |
| 有效期 | 作者推送新提交后旧批准是否失效，取决于仓库设置 |
动作与影响对照
| 动作 | 含义 | 对合并的影响 |
|---|---|---|
| Comment | 留下评论但不表态 | 不阻塞合并；除非规则另有要求 |
| Approve | 批准改动 | 计入所需批准数，满足后允许合并 |
| Request changes | 要求先修改 | 默认阻止合并，处理并经复核后解除 |
该选哪个动作
- 只是提问或补充说明：用 Comment，不要用请求修改制造阻塞。
- 确认没有阻塞性问题：用 Approve，需要说明的建议标 nit 一并给出。
- 发现必须修的缺陷（正确性、安全、兼容性）：用请求修改并列清清单。
- 方案分歧而非缺陷：先用评论讨论，不要把偏好写成阻塞。
- 同时写了多条意见：先判断有没有阻塞项，再决定动作，意见数量不决定动作。
流程配置相关
- 仓库可开启「推送新提交后忽略旧批准」，避免未审的新代码沿用旧批准。
- 提出请求修改后作者已修复：评审者需主动复核并重新批准，否则改动一直卡着。
- 需要意见逐条落地时，可要求「所有对话已解决」才能合并。
- 批准人选择：涉及多模块的大改动可请多人分别覆盖，避免一个人扛全部判断。
Request changes 是重锤：能用普通评论说清的就别用它，避免无谓地卡住合并。
GitLab 的 MR 有类似机制：任一评审者请求修改即阻止合并，直到问题被解决或对方撤回。