我经常使用git rebase --interactive来清理历史记录。它发生有合并冲突，或者即使没有冲突，仍然有合并。即使我只改变了提交的顺序，压扁它们等等，我总是有点害怕某些事情发生了变化。
我过去常常将工作树的备份副本粘贴到新工作树上。然后我查看了gitg中的提交窗口，看看是否一切都是一样的。虽然这很痛苦但我不再制作备份副本了。
接下来我做了一个备份分支，我发现git diff backup-branch有效。
现在我尝试了:(因为我也想停止制作备份分支）
git --diff HEAD ORIG_HEAD
但是这显示了我的变化，当我查看工作目录中的文件时，看起来它没有改变。
此方案的正确命令是什么？
答案 0 :(得分：2)
在这种情况下，交互式rebase通过结帐开始，并且出于某种原因，在结账后设置了 ORIG_HEAD。实际上你想要在rebase执行checkout之前对HEAD的提交进行区分。你可以在reflog中找到它：
git reflog
查找最接近顶部的结帐，并在下一行中查看提交。如果您的reflog看起来像这样：
ec4bd97 HEAD@{0}: rebase -i (finish): returning to refs/heads/big_cat_branch
ec4bd97 HEAD@{1}: rebase -i (fixup): Divide the bug class into modules
5d62142 HEAD@{2}: rebase -i (fixup): updating HEAD
c28c562 HEAD@{3}: checkout: moving from big_cat_branch to c28c562
7f6bc0e HEAD@{4}: commit: Fix bug related to big cats.
那么你想要像这样区分：
git diff HEAD 7f6bc0e
或
git diff HEAD HEAD@{4}
除非交互式rebase实际上改变了代码中的内容，否则你不会期望输出。
如果你能从reflog中获取该条目会很好，但除了获得ORIG_HEAD指向的提交（使用git rev-parse ORIG_HEAD）之外我不知道一个简单的方法，在reflog，并查看以下行。你可以写一个脚本来做，但手动找到它并不难。
（您可能认为ORIG_HEAD ^会为您提供您想要的内容，但这会在提交历史记录中提供ORIG_HEAD 之前的提交，而不是在您的本地reflog中。您需要后者。）
答案 1 :(得分：0)
我个人喜欢git log -p。我展示了每次提交的差异，包括合并。