先选好提交与分支对比，再审查改动

审查之前，先想清楚要回答什么问题。“这个提交改了什么”和“这个分支从分叉以来改了什么”，即使涉及同样的分支名，得到的 diff 也可能不同。

想先了解它是否适合你的任务？查看 Mac Git 差异查看器的用途与限制，再按下面的步骤打开对比。

打开对比

以审查 feature 相对 main 的改动为例，操作时换成你自己的分支名：

打开本地 Git 仓库，点击文件栏中的版本比较…。
从提交切换到比较。
在旧版本（base）一栏选择本地分支，选中 main；在新版本（head）一栏选择本地分支，选中 feature。两栏各有自己的分支来源和搜索框。
想看 feature 从分叉后做的工作，选分叉以来；想比较两个分支当前的内容，选直接比较。下一节会解释结果为什么不同。
核对底部摘要里的分支名和短提交 ID。方向选反了就点对调新旧，确认后点查看改动。
在变更文件树里选一个文件，查看行内 diff。

如果要以 origin/main 为基准，在旧版本一栏改选远程分支。这里列的是本机仓库已有的远程跟踪引用，不会实时查询服务器。需要远程的新提交时，先用平时的 Git 客户端更新仓库，再重新打开版本选择窗口。

Yenpo 会把对比固定到具体的提交上。分支之后再往前走，正在审查的提交也不会变。要审查分支上新的提交，就新建一个对比。

以下面这段历史为例：

      M1──M2  main
     /
O───X
     \
      F1──F2  feature

直接比较 main → feature，比的是 M2 和 F2，两边各自做的改动都会混进来。分叉以来比的是 X 和 F2，通常更适合回答“feature 分支加了什么”。它不会模拟最终的合并结果，也不能告诉你合并时会不会冲突。

审查 merge commit 时，提交模式只和第一个父提交比较。这只是看合并的一种角度，不会分别和每个父提交比较，所以先确认它正好回答你的问题。

把鼠标停在变更文件树上方的版本信息上，可以看到完整提交 ID。直接比较显示的是选中的旧版本和新版本；分叉以来的基准标记为 merge-base(...)，对应共同祖先的 ID，而不是旧版本分支的最新提交。

也可以在同一个仓库的终端中运行下面两条只读命令，核对相同的版本。先把 BASE_COMMIT_OID 和 HEAD_COMMIT_OID 换成 Yenpo 中显示的两个完整 ID：

git show --no-patch --format='%h %s' BASE_COMMIT_OID HEAD_COMMIT_OID
git diff --stat BASE_COMMIT_OID HEAD_COMMIT_OID --

第一条确认两个提交，第二条汇总这两个已提交版本之间的文件差异；当前未提交的修改不在这个范围里。复查之前的审查时要用当时的 ID，分支名现在可能已经指向新提交。

在变更文件树里点开文件，会打开只读的行内 diff。对比中的文件可以和当前文件同时打开，所以分析调用方或测试之前，先确认每个标签页显示的是哪个版本。你的项目里可能已经有选中的 head 里没有的改动。

对每一处会影响行为的修改，多读几步：

一个叫“处理并发读取”的测试，可能只是先后调用了两次。要看它的准备步骤和断言，别只看名字。Promise 缓存审查里有具体例子。

点击对比栏中的让 AI 审查这次比较按钮。它会准备一份已附加当前对比的草稿，还不会发送请求。先核对对比标签，再按自己的审查重点修改草稿，确认后发送。尚未连接模型的话，先按连接模型服务商完成配置。

例如：

检查这次改动有没有引入取消和错误处理方面的回归。每个发现都请给出改动位置、触发它的状态、用户会看到什么，以及支撑结论的代码。基线里原来就有的问题请单独列出。

逐条确认它给出的触发条件在选中的提交里真的会发生。只读代码判断不了执行顺序时，让它给出复现步骤或针对性的测试，再自己运行。回答里的测试并没有跑过。

Git 对比对话始终只读。要修复，就针对当前项目另开一个普通对话，打开允许修改。对比可以留着作参考。

改完后，查看项目 diff，自己运行项目的检查。停止运行不会撤销已经写入的文件。如果项目原本就有别的改动，决定提交哪些之前，先把它们和这次修复分开。