应使用三点比较变基前后差异，因双点比较同一分支快照结果为空；需通过git reflog定位变基前提交（如feature@{2}），再用git diff feature@{2} feature获取净变化。
git diff 用双点还是三点？先搞清你比的是什么
变基（git rebase）会重写提交历史，所以“变基前 vs 变基后”的差异不是简单比较两个分支名就能得出的。如果你直接跑 git diff feature..feature，结果永远是空——因为这是同一分支的两个快照。关键在于：你要比的到底是「逻辑内容是否一致」，还是「提交对象是否被重写」。
常见错误是以为 git diff feature-old feature-new 就行，但 Git 没有自动记住哪个是“旧版 feature”。你得自己标记或推导出变基前的原始提交位置。
用 git reflog 找到变基前的 HEAD 位置
git reflog 是唯一可靠的方式，它记录了每次 HEAD 移动（包括 rebase 开始前、中断时、完成后的状态）。变基操作会在 reflog 中留下类似这样的条目：
feature@{0}: rebase finished: returning to refs/heads/feature
feature@{1}: rebase started: checkout master
feature@{2}: commit: add login validation
其中 feature@{2} 就是变基开始前那个最后一次提交的引用——也就是你要比对的“旧版本”起点。
- 运行
git reflog feature查看该分支的历史移动轨迹 - 找到带
rebase started或紧挨着它的上一条commit记录，记下那个@{n}编号 - 用
git diff feature@{n} feature得到变基前后代码内容的净差异
用 merge-base 验证是否真有内容变化
如果变基只是线性重放、没改代码，git diff 应该为空。但有时因冲突解决引入了额外修改，或者变基过程中误删/改了东西。这时光看 diff 不够，还得确认「变基是否改变了功能语义」。
推荐组合使用：
-
git merge-base feature@{n} feature：查共同祖先。如果输出是feature@{n}自身，说明变基后分支是从原点直接重放，无中间合并污染 -
git diff $(git merge-base feature@{n} feature)..feature：只比从共同祖先到当前分支的变更，排除掉可能混入的其他分支改动 - 若你担心变基中 cherry-pick 错了提交，可用
git log --oneline feature@{n}..feature看新增了哪些提交哈希，再逐个git show <hash>核对
变基后想恢复？别只靠 diff，先看 reflog 是否还在
很多人比完发现不对劲，立刻想 git reset --hard feature@{n} 回退——这确实可行，但有个硬限制：reflog 默认只保留 90 天（或 30 天，取决于配置 gc.reflogExpire）。2026 年 10 月的仓库如果在 7 月做过变基，feature@{n} 可能已被 GC 清掉。
真正保险的做法是在执行 git rebase 前手动打标签：
git tag rebase-before-feature feature- 完成变基后，随时可用
git diff rebase-before-feature feature - 标签不会被 GC 清除，比 reflog 可靠得多
这个动作花不了三秒，但能避免你在某天突然发现 reflog 断档、又没备份时彻底抓瞎。
