切换master分支后git合并到master分支

Question

我在合并时遇到了一个有趣的问题。我不太清楚如何解释，所以我希望这张图能给你一个更清晰的想法：

基本上，紫色的分支曾经是主分支，但后来我需要恢复到以前的提交以进行不同的更改。当我想这样做时，我使用指令here 切换了主分支，但是从图中可以看出，这会导致原始主节点“空”合并到新主节点（蓝绿色）。

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

我怎样才能真正合并这两个分支的内容？

Answer 1

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

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

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

你想要这个：

... A - B - Z1 [master]

Checkout B，cherry pick Z 在上面（即复制将成为新提交 Z1 的补丁），声明新的 master。

• git checkout B
• git cherry-pick Z
• git branch -f master

请注意，结果是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 来消除合并。

• git checkout master
• git rebase Y

---

这一切都取决于 Y 和 Z 在做什么。它们有关系吗？是 Z 并试图修复 Y 中的某些东西吗？如果是这样，那么将 Y 视为自己的分支为时已晚。合并分支后，停止将其视为分支。 Y 现在是 master 的一部分，只需修补 master。