作为snakecharmerb said in a comment，这两种方法都有效——但我会说你最好修复修复提交。
当您使用--fixup 时，您在git log 中看到的内容非常简单：Git 进行提交，其提交消息的形式为fixup! <em>subject</em>。例如，这就是您的提交 efgh 显示的内容。 （注意：abcd 是有效的缩写哈希 ID，但 efgh 不是，因为这里的字母和数字来自 hexadecimal 表示法：提交的哈希 ID 只是一个数字，通常以十六进制表示，并且通常缩写为大约 7 个字符。任何至少 4 个有效的十六进制字符都算在内；SHA-1 哈希的全长是 40 个字符，SHA-256 哈希的全长是 64 个字符。）
如果你运行：
git commit --fixup abcd
再次，您将获得与您的efgh 完全相同的提交消息的另一个提交。如果你运行：
git commit --fixup efgh
你会得到一个消息是fixup! fixup! Add sth。
稍后当你实际运行git rebase --autosquash 时，Git 中的机制是这样工作的：
- rebase 代码枚举所有要复制的提交，最初使用
--topo-order（请参阅git rev-list 和/或git log 手册）。
- rebase 代码然后使用交互式 machinery——Git 称之为 sequencer。在较旧的 Git 版本中，这是一种特殊情况；在现代 Git 中，rebase 无论如何都默认使用排序器，所以此时没有什么特别的事情发生。
- 但现在 Git 正在使用排序器，Git 有一个（内部）“说明表”，其中包含
pick 命令。这是您在使用git rebase --interactive 时可以查看和编辑的说明表。
正如文档所述，这个交互式（基于序列器的）变基表如下所示：
pick deadbee The oneline of this commit
pick fa1afe1 The oneline of the next commit
...
--autosquash 所做的就是在您有机会编辑此工作表之前对其进行修改。代码首先查找消息以fixup! 或squash! 开头的提交。找到这样的提交后，代码如下：
- 找到与此消息匹配的提交（并且此找到的提交必须在当前提交之前，即要在工作表中移动）；
- 将 this 提交放在该提交之后，在工作表中；和
- 将
pick 替换为fixup 或squash。
文档中的实际措辞继续提到也将使用哈希 ID；这是来自 Git 2.37 文档的引用：
--autosquash, --no-autosquash
当提交日志消息
以“squash！...”或“fixup！...”或“amend！...”开头，然后
已经是待办事项列表中与相同... 匹配的提交，
自动修改rebase -i的待办事项列表，使commit
在要修改的提交之后立即标记为挤压，
并将移动提交的操作从 pick 更改为 squash
或 fixup 或 fixup -C 分别。提交匹配 ...
如果提交主题匹配，或者... 指的是
提交的哈希。作为后备，提交的部分匹配
主题工作，也是。创建修复/修改/壁球的推荐方法
提交是通过使用--fixup、--fixup=amend: 或
--fixup=reword: 和 --squash 选项分别为
git-commit[1].
（修改和改写选项是 Git 2.32 中的新选项。）
测试表明，如果您有两个或多个提交，fixup!相同的主题，Git 会将修正按“拓扑顺序”排列——也就是说，第二个修正在第一个修正之后应用，而不是之前。 （这就是我们想要的。）但是如果你有fixup! fixup! ...，文档的措辞将强制 Git 将它们按拓扑顺序排列，因为第二个修复必须匹配主题现在以开头的提交一个fixup!。这就是我建议修复修复提交的原因。