交互式 rebase 或整理补丁后，只看最终文件 diff 不太容易发现某个提交被漏改。可以先记住旧分支位置，再比较两组提交：
old_tip=$(git rev-parse HEAD)
git rebase origin/main
git range-diff origin/main...$old_tip origin/main...HEAD
输出会按提交配对，标出新增、删除和内容变化，适合推送前快速复查。环境：Git 2.25+。它只做比较，不会修改历史；如果 rebase 中途失败，先处理或退出 rebase，再执行最后一行。
提交改动比较大、默认配对不准时，还可以试试 --creation-factor=80。数值调高后，Git 会更倾向于把差异较大的两个提交视为改写前后的一对；不过也可能误配，还是要结合提交标题和补丁内容看。
如果整理过程可能跨终端，old_tip 这个 shell 变量容易丢。可以先建个临时引用：
git branch backup/pre-rebase HEAD
之后把命令里的 $old_tip 换成 backup/pre-rebase，确认无误再用 git branch -d backup/pre-rebase 删除。这样中途需要回看旧提交也更方便。
隔壁空白Lv1#2 如果整理过程可能跨终端，
old_tip这个 shell 变量容易丢。可以先建个临时引用：git branch backup/pre-rebase HEAD之后把命令里的
$old_tip换成backup/pre-rebase，确认无误再用git branch -d backup/pre-rebase删除。这样中途需要回看旧提交也更方便。
这个思路再补一个小坑：如果整理过程跨得比较久，origin/main 可能在中途被 fetch 更新，前后两次比较就不一定是同一个基线。可以先固定基线：
base=$(git rev-parse origin/main)
git branch backup/pre-rebase HEAD
git rebase origin/main
git range-diff $base...backup/pre-rebase $base...HEAD
这样看到的才是相对同一版基线的提交变化；如果 rebase 失败，先处理或 git rebase --abort，确认不用备份引用后再删。
Nathan03Lv1#3 这个思路再补一个小坑：如果整理过程跨得比较久，
origin/main可能在中途被 fetch 更新，前后两次比较就不一定是同一个基线。可以先固定基线：base=$(git rev-parse origin/main) git branch backup/pre-rebase HEAD git rebase origin/main git range-diff $base...backup/pre-rebase $base...HEAD这样看到的才是相对同一版基线的提交变化；如果 rebase 失败，先处理或
git rebase --abort，确认不用备份引用后再删。
补充一点：如果 rebase 实际落到了更新后的 origin/main，旧基线和新基线最好分别记录，不能只固定一个值，否则上游新增提交也会混进比较结果。可以这样写：
old_base=$(git rev-parse origin/main)
git branch backup/pre-rebase HEAD
git fetch origin
git rebase origin/main
new_base=$(git rev-parse origin/main)
git range-diff $old_base...backup/pre-rebase $new_base...HEAD
这样比较的是两组各自相对基线的提交序列；如果不希望 rebase 使用 fetch 后的新基线，就跳过 git fetch，并保持前后的基线引用一致。
隔壁空白Lv1#2 如果整理过程可能跨终端，
old_tip这个 shell 变量容易丢。可以先建个临时引用：git branch backup/pre-rebase HEAD之后把命令里的
$old_tip换成backup/pre-rebase，确认无误再用git branch -d backup/pre-rebase删除。这样中途需要回看旧提交也更方便。
有个删除时的小坑：rebase 改写历史后，旧提交通常不是当前分支的祖先，git branch -d backup/pre-rebase 可能会拒绝。确认 range-diff 和新分支都没问题后，需要用 git branch -D backup/pre-rebase；-D 会强制删除，所以先保留一会儿反而更稳。