上游 · 理解本功能前需先掌握的（1）：
下游 · 依赖/承接本功能的（0）：
暂无下游（建议学完它再进阶）
前置依赖包含从属概念升级流程承接
边方向 = 学习顺序（A→B 表示先学 A 再学 B）
为什么需要它
心智模型
自己看自己的代码总会有盲区，就像自己检查自己写的作文很难发现错别字。代码评审（Code Review）让另一个人（或一组人）在代码合入前帮你把关，揪出 bug、提改进建议、确认符合团队规范。它是开源社区和团队工程的质量防线，能让错误在进入主分支前就被拦住。
历史背景 · 它为什么诞生诞生于 2010/2016
诞生开源协作从"邮件补丁评审"转向"平台内评审"：提交者与维护者需要在代码上下文中讨论改动。2010 Pull Requests 2.0把PR变成"活的代码讨论"，支持提交行内注释与版本感知，是评论式review雏形。
演进2016-09-14推出正式Reviews，支持approve/request changes与review summary，配合protected branches要求必须评审通过才能合并；此后演进出request review指派、Copilot代码评审等，从"可选讨论"变为"强制质量门禁"。
历史教训
同一个需求（让人审查你的代码）会随协作规模升级形态：从散落的评论到结构化审批再到自动化质量门槛。评审机制的"门禁化"使其从辅助功能上升为团队质量治理的核心。
功能介绍
代码评审（Code Review）是指对拉取请求（Pull Request）中的代码变更进行审查的过程，这也是官方 GitHub 流程（GitHub flow）的第四步：处理评审意见（Address review comments）。当有人向你发起评审请求（Review Request）时，你会收到通知，然后在 PR 的 Files changed 页面逐行查看改动。你可以做三件事：针对某一行或整个文件留下评论（Comment）；在整体意见上批准合并（Approve）；或者请求修改（Request changes）。作者的职责是逐一回应每条评论、修改代码、再推送到同一分支，评审人确认后才会点合并。很多团队会用「分支保护（Branch Protection）」规则强制要求：必须至少一位评审人批准（approved）才能合并，用规则保证质量。所以 Code Review 不只是挑毛病，更是一种知识传递——新人通过看别人的评审学会更好的写法。
核心术语
代码评审（Code Review）评审请求（Review Request）批准（Approve）请求修改（Request Changes）分支保护（Branch Protection）
适用场景
- 当你收到别人的 PR、需要把关代码质量时，进入 Files changed 页面评审。
- 当你希望自己的改动被他人检查后再合并时，主动在 PR 里 @ 团队成员请求评审。
- 当团队开启分支保护、不批准就无法合并时，认真完成每一次评审。
- 当你在评审中发现问题时，用逐行评论（Comment）或请求修改（Request changes）反馈。
怎么操作（网页 vs 命令行 双轨）
🖱️ 网页操作 (GitHub.com)
- 打开待评审的 PR，点击 Files changed 标签查看全部代码差异。
- 把鼠标移到代码行上，点 + 号留下逐行评论。
- 评审完成后点 Review changes，选择 Comment / Approve / Request changes 并提交。
- 作为作者：回应每条评论、推送新提交，直到评审人批准后点 Merge。
⌨️ 命令行 (进阶)
gh pr checkout 123gh pr review 123 --approvegh pr review 123 --comment --body "建议改这里"gh pr review 123 --request-changes --body "需要修复"
新手建议先从网页操作入手，熟悉概念后再尝试命令行。命令行是真实开发中更常用的方式。
与其他功能的关系
| 关系（前置依赖 / 包含从属 / 概念升级 / 流程承接） | 说明 |
|---|---|
| 流程承接拉取请求（Pull Request） | PR 打开后进入评审环节 |
官方文档
小结
SUMMARY
Code Review 就是在合入前请别人帮你检查代码，核心动作是评论、批准、请求修改。记住：好团队靠规则强制评审，而不是靠自觉。下一步学协作者权限，掌握怎么把信任的人加进你的仓库。