只看增量为什么高效
复核一轮修改时，评审人通常只需要看「上次评审之后新增了什么」。平台为此提供了增量视图，也可以在命令行里直接对比两次提交。作者在回复里主动给出本轮改动范围的摘要，配合增量视图效果最好，评审人不必重新通读全部代码。
基本信息
| 平台增量视图 | 变更页面里的增量对比入口 |
|---|---|
| 命令行方式 | git fetch 之后用 git diff <上次提交>..<新提交> |
| 前置数据 | 依赖平台保留的推送版本记录 |
| 作者配合 | 在回复中给出本轮改动范围摘要 |
典型使用场景
- 复审一轮修改时只看新增改动，节省重复阅读的时间
- 确认作者是否只改了被要求修改的地方
- 大改动分多次迭代时逐轮核对增量
- 用命令行检出到本地后做精确到文件的差异比对
- 交接或归档时确认某一轮评审对应的确切内容
命令行复核增量
命令行复核增量
git fetch origin pull/128/head:pr-128 # 把评审请求内容抓到本地分支
git log --oneline pr-128 # 查看该分支的提交清单
git diff pr-128~2..pr-128 -- src/login.js # 只看最近两次提交中该文件的改动
git diff origin/main...pr-128 --stat # 查看相对目标分支的改动概览查看方式对照
| 方式 | 入口 | 适用情况 |
|---|---|---|
| 平台增量视图 | 变更页面的增量对比 | 在网页上快速复核一轮改动 |
| 版本对比 | 合并请求的版本切换 | 平台保留了多次推送记录时 |
| 命令行差异 | 抓取分支后对比提交 | 需要精确到文件或具体行 |
强推覆盖历史之后，平台的增量对比可能重置，作者需要重新说明本轮改动范围，评审人也别继续依赖旧的增量视图。
只看增量容易忽略全局影响：涉及接口签名、公共数据结构或配置默认值的改动，仍建议复读一遍完整差异。
评审轮次较多时，把每一轮的增量范围在讨论里记下来很有用：事后回看时能说清哪一轮改了什么，也方便在交接时把上下文交给下一位评审人。