Question

我有一个有趣的合并问题。我不确定如何解释它，所以我希望这个图表会给出一个更明确的想法：

基本上，紫色USED中的分支是主分支，但后来我需要恢复到先前的提交以进行不同的更改。当我想要这样做时，我使用here指令切换了主分支，但正如您从图中看到的那样，这会导致＆＃34;空＆＃34;将原始主人合并到新主人（在蓝绿色）。

现在，我现在实际上想要将紫色提交合并回master，这两个提交都来自同一个原始提交。在尝试合并回master之前，我对紫色提交做了一些更改（如最近的第2次提交所示）。但是，当我尝试合并时，没有给出选项，因为git认为合并已经发生（因为＆＃34;空＆＃34;合并在图的底部）。

如何实际合并这两个分支的内容？

Answer 1

让我们分别处理这两个提交。首先是最近的一个。

你有这个。 M是合并，Z是最新的紫色提交。

... A - B - M [master]
           /
      ... Z

你想要这个：

... A - B - Z1 [master]

Checkout B，樱桃挑选Z在它上面（即复制将成为新提交Z1的补丁），声明新的主人。

请注意，结果是master指向Z1，而不是Z。内容相同，ID不同。 Git并没有重写历史，因为它创造了新的历史。您的存储库实际上看起来像这样：

... A - B - Z1 [master]
         \
  ... Z - M

没有任何指向M（记住，git中的连接向后），它将被垃圾收集。然后Z将没有任何指向它，它将被垃圾收集。

第二次紫色提交比较棘手。到目前为止，你可能不想在没有充分理由的情况下搞砸它。没有看到它的祖先，很难知道它可以做些什么。您向我们展示的是：

...   M2 - D - E ... A - B - Z1 [master]
     /
... Y

在不知道M2和Y之前的情况下，我们无法判断重写历史是否安全，或者是否应该单独进行合并。它看起来像这样：

... F - G - H - M2 - D - E ... A - B - Z1 [master]
               /
...   W - X - Y

在这种情况下，它是合法的合并，应该保持独立。或者看起来像这样：

... H - M2 - D - E ... A - B - Z1 [master]
     \ /
      Y

在这种情况下，你可以通过在Y之上重新定位master来消除合并。

这一切都取决于Y和Z在做什么。它们有关系吗？是Z并尝试修复Y中的某些内容吗？如果是这样，将Y自己的分支考虑为时已晚。一旦分支合并，就像分支一样停止对待它。 Y现在是master的一部分，只是补丁大师。