如何使用正常提交压缩合并提交？

Posted 2021-05-04

commit b0e5db36ed68d4562275adeb08001b1316a4da52
Merge: ea38baa 8220bb1

commit ea38baa3f46a48722987b8dd3892d2b8d81c4d1a

在这种情况下，我如何压缩这两个提交

我在用

git rebase -i HEAD~2

但这不起作用，因为它删除了合并提交，并且不能用于压缩

答案

这里要考虑两个因素：

首先，在几个方面，rebase并不总是与合并提交很好。我会回到那几次。

其次，你所期待的结果并不完全清楚。如果你现在有类似的东西

x -- x -- M -- C <--(master)
        /
  A --- B

你想结束吗？

x -- x -- ABC <--(master)

要么

x -- x -- MC <--(master)
        /
  A --- B

如果你想要带有ABC的版本，那就非常简单了。虽然M没有出现在一个rebase的TODO列表中，但M（即本例中的A和B）带入主线的所有提交都是。因此，只需将B和C标记为“壁球”。唯一要记住的是，这是一个历史重写，所以如果你已经推动任何可以达到A，B，M或C的refs，那么可能需要进行一些清理（参见“从上游恢复”下的rebase文档变基“）。

如果你想要版本与MC，那么有很多问题。并不是说你无法得到它，但我认为你不能通过做一个rebase得到它;而且，MC将是一个“邪恶的合并”，这可能导致未来rebase尝试的问题（除其他外）。

默认情况下，rebase会尝试生成线性历史记录，并且不会生成合并提交。您可以使用--preserve-merges选项生成合并提交，但这与-i不能很好地交互（如果您尝试通过执行修改合并，我预计会有几个可能的问题）。

如果你不担心在合并提交中隐藏更改的问题，并且真的想要生成像MC这样的提交，那么这样做的方法是：

首先，将master ref移回M，同时保持C在索引中的变化。

git checkout master
git reset --soft HEAD^

然后将更改直接重新应用于合并提交

git commit --amend