Git重置HEAD〜1提交错误

问题描述

我读到了有关承诺，父母和祖先的信息。为了获得更多的澄清，我尝试进行试验并创建了一个测试git repo。我的目标是将3个分支合并到master分支，以了解父母和祖先之间的差异。以下屏幕截图是git log的修饰。

正如我们在日志中看到的，合并提交44f1883似乎有三个父级，即4385eae，7288d94和ee647fe。我不明白为什么它也没有98c9d28作为父项。我认为98c9d28应该是它的直接上级，因此如果从master开始运行git reset HEAD~1，它将使我进入commit 98c9d28，这是我做之前的状态合并，但不幸的是，它使我到达4385eae，这在逻辑上是不正确的（尽管从日志角度来看是正确的）。

我想念什么吗？

解决方法

您看到的是git merge在给出不寻常的命令时会尽力提供帮助。

在master中，您必须说过

git merge branch1 branch2 branch3

这是允许的，并执行“章鱼合并”，但这不是合并分支的常用方法-通常一次合并一个分支。当您使用章鱼合并时，存在一些局限性（通常不会很好地解决冲突）。而且即使行为正常，如您所见，也可能有些奇怪。

如果您看一下merge命令的输出，您会发现它使用了到branch1的快进，然后从那里对其余分支执行合并。大概是为了减少章鱼合并的复杂性。

（（如果您不熟悉merge的快进行为...基本上git会发现master不包含branch1中尚未存在的更改，因此与其合并即可将master移至branch1。）

在任何情况下，您可能希望也可能不希望git使用快进，在这种情况下，这可能会特别令人困惑，因为快进会立即与其他合并操作结合使用，从而使发生的情况变得不太明显-以及就像您说的那样，导致最终图形可能看起来不像您期望的那样。

因此，您可以将--no-ff选项添加到您的merge命令中，然后它将无法执行此操作。 （有趣的是，在我的测试中，输出仍然表明使用了快进；但是最后的图显示了所有4个父代。很可能它仍然使用快捷方式算法来尝试产生结果，但是记录提交就像还没有。）

但实际上，我还是要警惕章鱼的融合。