GitHub 评审动作对比
| 动作 | 含义 | 对合并的影响 |
|---|---|---|
| Comment | 留下评论但不表态 | 不阻塞合并（除非分支规则要求批准数） |
| Approve | 批准改动 | 计入所需批准数，满足后允许合并 |
| Request changes | 要求先修改 | 默认阻止合并，处理并经复核后可解除 |
Request changes 是重锤：能用普通评论说清的就别用它，以免无谓卡住合并。
三种评审动作：评论、批准、请求修改
GitHub 评审模型的三种提交方式：Comment（仅评论）、Approve（批准）、Request changes（请求修改，默认阻止合并）。
易错点
- 一直挂着 Request changes 但作者已修复：忘记重新批准，改动被卡死
- 把 Request changes 用于方案偏好之争：应转到讨论而不是卡合并
数据来源与参考
- GitHub Docs · Reviewing proposed changes in a pull request