关键在于让评审人一眼抓住重点：先用git diff --name-only和--stat快速筛选文件及改动规模；再用VSCode行级注释或difit网页工具标记P0项、过滤文件、压缩上下文（-U0），并人工核查二进制变更与语义影响。
直接用 git diff 配合可视化工具，比手动翻提交日志快 5 倍以上——关键不是“怎么 diff”，而是“diff 出来之后怎么让评审人一眼抓住重点”。
git diff --name-only 和 --stat 要先跑一遍
评审前不看文件列表，等于蒙眼开车。这两个参数能快速筛出“改了哪些文件”和“改得多不多”：
-
git diff --name-only main feature/auth：只输出变更文件路径，适合复制进评审 checklist -
git diff --stat main feature/auth：显示每文件增删行数（如src/api/user.ts | 12 +-），一眼识别高风险大改文件 - 如果输出里出现
package.json或webpack.config.js，说明可能有依赖或构建层影响，需额外标注 - 避免用
git diff main..feature/auth（双点）代替git diff main feature/auth（空格）：前者是“main 到 feature 的可达路径差异”，后者才是“两个分支 tip 快照的直比”，语义更稳
VSCode 内置 Diff 编辑器里加行级注释
本地评审时，别只看终端输出。VSCode 的 Git: Compare Branches 命令（Ctrl+Shift+P 输入触发）打开后，每个变更行左侧有 + / - 标记，这时可以直接右键添加评论：
- 点击某行左侧的
+区域 → “Add Comment”，写明“这里是否需要空值校验？”或“该逻辑是否覆盖了 error case？” - 注释会保存在本地工作区，导出为 HTML 或截图发给同事时，这些标记仍可定位到具体行
- 注意：VSCode 默认不把注释提交到 Git，所以不会污染代码库；但若用
difit工具启动的 Web 界面，它的评论是临时的、不持久，关掉就丢 - 别在
git diff --no-index（对比任意两文件）场景下依赖这个功能——VSCode 只在 Git 仓库内且有明确分支上下文时才启用完整评论链
用 difit 启动 GitHub 风格审查页，带文件过滤和 P0 标记
difit 是目前最贴近真实 CR 流程的本地工具，它把 git diff 结果转成带交互的网页，省去粘贴、截图、对齐行号的麻烦：
- 运行
difit main feature/auth，自动打开http://localhost:4966，左侧是文件树，支持按.ts、test、config过滤 - 在关键文件上点击右上角 ⚠️ 图标，可手动标记为“P0 必审”，刷新后该文件名会变红，方便跳过低风险项
- 它默认忽略空格和换行差异（等价于加了
-w参数），但如果评审要求检查格式变更，得手动停用：启动时加--no-ignore-space-change - 注意：
difit不解析 commit message，所以如果你靠 message 里的 “BREAKING CHANGE” 来判断兼容性，得自己补查git log -p -n 5 main..feature/auth
别让 git diff 输出淹没重点
原始 git diff 输出里，80% 是上下文行（@@ 行及前后几行），真正改动往往只有中间一两行。评审时最容易卡在这儿：
- 加
-U0参数压缩上下文：git diff -U0 main feature/auth，让每个 hunk 只显示变更行本身，适合发 Slack 或邮件摘要 - 遇到大量重命名/移动文件，
git diff --find-renames=40%比默认的 50% 更敏感，能捕获小范围重构（如函数拆分后重命名） - 如果 diff 里出现二进制文件（
Binary files a/logo.png and b/logo.png differ），别跳过——立刻用git show main:logo.png > old.png提取旧版，用图像工具人工比对，CI 通常不校验这类变更 - 最常被忽略的一点：diff 显示的是“文本变化”，不是“执行效果”。比如改了正则表达式
/\d+/→/\d{3,}/，diff 看着就一行，但实际可能拦住所有两位数字输入——这种语义级影响，必须结合测试用例或文档补读
