当我在分支中压缩提交时（使用 git rebase -i），我总是对压缩的提交与旧提交而不是新提交相结合感到恼火。
我不明白为什么它是这样设计的。当我提交正在进行的工作 (WIP) 时，它表示未编译或未完成的代码。当我最终提交“它终于起作用了！” 在合并之前提交和压缩，将这些 WIP 提交合并为“它终于可以工作了！”更有意义。提交，而不是与之前的提交合并。使用我知道无法编译的代码压缩 WIP 实质上会“破坏”之前的提交。
为了解决这个问题，我的工作流程是从“它有效！”中压缩提交。一直回到第一次 WIP 提交之前的一个。但这不是很愚蠢吗？其他人在做什么，这使得将 WIP 压缩到先前的提交是有意义的？
将您的最新提交压缩到较旧的提交中应该可以避免两者之间的差异。仅仅因为您正在“挑选”较旧的提交，并不意味着您修复正在进行的提交中的错误的新工作被排除在外。
尝试使用git rebase -i HEAD~4，但将 4 替换为您想要组合的提交数，从 HEAD 开始，这大概是您的工作状态。
在http://gitready.com/advanced/2009/02/10/squashing-commits-with-rebase.html上有一个很好的关于使用交互式 rebase 的指南。
那么为什么不使用git reset --soft, 来重置HEAD（并且仅HEAD）回到第一个 WIP，并从那里提交（使用最近和最终工作的 WIP 的索引和工作树）。
这样，您可以快速将这些提交压缩在一起。
请参阅“如何使用 git 将我最后的 X 提交压缩在一起？ ”
这反映了我对“实际用途git reset --soft？ ”的结论：
每一次：
- 您对最终得到的结果感到满意（就工作树和索引而言）
- 您对带您到达那里的所有提交都不满意：
git reset --soft是答案。