PR rebase 或者改写提交后，直接看普通 diff 往往不太容易判断每个提交有没有漏改。Git 2.19+ 可以用 git range-diff 对比两组提交范围。
git range-diff origin/main...old-topic origin/main...new-topic
如果旧分支和新分支的基点不一样，也可以把两边的提交范围明确写出来：
git range-diff old-base..old-topic new-base..new-topic
它会按提交匹配并标出每个提交的新增、删除和变化，适合 rebase 后给自己做一次快速复核。命令只读本地提交，不会修改工作区；仓库里要先有旧提交和新提交这两组对象。
这个在 rebase 后特别有用。补一个容易忽略的点：两边的范围最好都明确写成各自基点到分支的提交区间，比如 old-base..old-topic new-base..new-topic，这样不容易把基点本身也混进比较里。
如果提交信息被改得比较多，可以加 --no-dual-color 看纯净的 diff；输出里某个提交显示成 ! 时，值得再检查一下实际补丁是不是发生了变化。
ZiorLv1#1 这个在 rebase 后特别有用。补一个容易忽略的点：两边的范围最好都明确写成各自基点到分支的提交区间，比如
old-base..old-topic new-base..new-topic，这样不容易把基点本身也混进比较里。如果提交信息被改得比较多，可以加
--no-dual-color看纯净的 diff；输出里某个提交显示成!时，值得再检查一下实际补丁是不是发生了变化。
还有个小技巧是 --creation-factor=<n>。如果 rebase 后提交被拆分或合并，默认匹配不太理想时可以调这个值再看一遍；它只是影响提交配对的启发式，不代表补丁内容一定相同。最后还是要重点看标成 ! 的提交。
我会再补一步：range-diff 里看到 ! 后，先用 git show 对照对应的旧、新提交，再用 git diff old-topic new-topic 看最终树有没有实际差异。前者适合定位是哪一个提交的补丁变了，后者适合确认 rebase 后整体结果；只看其中一种，有时会漏掉提交拆分或合并带来的变化。