为什么“Git rebase”会将提交压缩到先前的提交中，而不是随后的提交中？

Question

当我压缩分支中的提交（使用 git rebase -i）时，我总是很恼火，因为压缩的提交与旧的提交而不是新的提交结合在一起。

我不明白为什么要这样设计。当我提交正在进行的工作 (WIP) 时，它表示未编译或未完成的代码。当我最终承诺“它终于起作用了！” 在合并之前进行提交和压缩，将这些 WIP 提交合并到“它终于可以工作了！”中更有意义。提交，而不是与之前的提交合并。压缩 WIP 本质上是用我知道无法编译的代码“破坏”了之前的提交。

为了解决这个问题，我的工作流程是压缩来自“它有效！”的提交。一直回到第一次 WIP 提交之前的状态。但这不是很愚蠢吗？其他人在做什么，这使得将 WIP 压缩到之前的提交有意义？

Answer 1

使用当前的 Git 版本（从版本 2.32.0 开始包含；在提交 9e3cebd97cbd47909e683e617d5ffa2781f0adaa中引入），您可以fixup -C在交互式变基的待办事项列表中指定以选择压缩/修复时要使用的提交消息，例如

pick 456789 Finished topic XYZ
pick abcdef WIP your incomplete commit
fixup 012345 WIP resolving compiler errors
fixup 6789ab WIP adding unit tests
fixup cdef01 WIP refactoring
fixup -C 234567 Implemented feature ABC
pick 89abcd Another feature

最终将有 2 次提交：“已完成的主题 XYZ”和“已实现的功能 ABC”，而无需手动调整任何提交消息（因此可以避免删除所有这些“WIP”行）。

如果您仍想编辑最终提交消息，请使用-c而不是-C：

pick 456789 Finished topic XYZ
pick abcdef WIP your incomplete commit
fixup cdef01 WIP refactoring
fixup -c 234567 Implemented feature ABC
pick 89abcd Another feature

任何其他附加步骤都可以使用一行执行exec：

pick 456789 Finished topic XYZ
pick abcdef WIP your incomplete commit
fixup cdef01 WIP refactoring
fixup -C 234567 Implemented feature ABC
exec git commit --amend --reset-author -CHEAD
pick 89abcd Another feature

在 Git 2.32.0 之前，您可以使用以下待办事项列表来解决此限制：

pick 456789 Finished topic XYZ
pick abcdef WIP your incomplete commit
fixup cdef01 WIP refactoring
fixup 234567 Implemented feature ABC
exec git commit --amend -C 234567 # commit id from line above
pick 89abcd Another feature