如何在Mercurial中退出合并，然后再与该分支重新合并？

Question

我有两个分支，默认和branch1。我们团队中的一个人错误地将branch1合并。 branch1中的内容尚未准备好与默认值合并（它包含构建和部署环境的主要返工）。

我们做了'hg backout'的实验，退出合并（不确定这是正确的方法）。然后从默认情况下删除branch1中的更改​​，这很好 - 但我们不能使用branch1重新合并。

我们应该如何解决这个问题？

Answer 1

这里有许多场景你可能想要这样做，我会将每个场景作为标题，以便您可以找到适合您情况的场景。请注意，我还在学习Mercurial，如果我说错了，使用错误的术语，可以做得更好等等，我会指点。

没有进一步的更改，合并不共享（没有推/拉）

程序员已经合并，但没有做任何其他事情，也没有以任何方式与任何人分享变更

在这种情况下，只需丢弃本地克隆，并从安全存储库中获取新的克隆。

在合并之上进行本地更改，而不是共享

程序员已合并，并继续根据该合并进行工作。应保留合并后的更改集，但应删除合并本身。尚未与任何人共享更改（合并+以下更改集）

在这种情况下，我会做四个中的一个：

1. 尝试使用REBASE扩展，这会将更改集从一个位置移动到另一个位置。如果更改集基于合并引入的代码更改，则必须执行一些手动工作以协调差异。
2. 尝试使用MQ扩展来提取要保留在补丁队列中的变更集，然后将它们推回到其他位置。但是，就基于合并的更改而言，这将与REBASE扩展具有相同的问题
3. 尝试使用TRANSPLANT扩展程序将更改从一个位置“复制”到另一个位置。仍然存在与前两个​​问题相同的问题。
4. 再次完成工作，可能借助于差异工具在我想要丢弃的变更集中进行更改，并在正确的位置重新进行更改。

要摆脱合并变更集+所有以下变更集，有几个选项：

1. 在MQ扩展

   中使用strip命令

   hg strip <hash of merge changeset>
   

2. 克隆并拉取，并指定导致但不包括合并的变更集的哈希值。从本质上讲，通过从受损的克隆中拉出一个新的克隆来创建一个新的克隆，并避免拉入你不想要的合并。

   hg clone damaged -r <hash of first parent> .
   hg pull damaged -r <hash of second parent>
   

合并推送给其他人，控制克隆

程序员已经推送到主存储库，或推送给其他人，或从程序员库中取出的人。但是，您（如在开发人员组中）可以控制所有存储库，例如，您可以在完成更多工作之前与所有人联系并与他们交谈

在这种情况下，我会看看是否可以完成第1步或第2步，但可能必须在很多地方完成，所以这可能涉及很多工作。

如果没有人根据合并变更集完成工作，我会使用第1步或第2步清理，然后推送到主存储库，并要求每个人从主存储库中获取新的克隆。

合并推送，您无法控制克隆

程序员推送了mergeset，你不知道谁将拥有合并变更集。换句话说，如果你成功地从你的存储库中消除了它，那么仍然拥有它的人的偏离将会带回来。

忽略合并变更集并在两个分支中工作，就好像它从未发生过一样。这将留下一个悬垂的头。稍后，当你合并了两个分支时，可以为这个头做一个空合并来摆脱它。

  M         <-- this is the one you want to disregard
 / \
*   *
|   |
*   *
|   |

只需继续在两个分支机构工作：

|   |
*   *
| M |       <-- this is the one you want to disregard
|/ \|
*   *
|   |
*   *
|   |

然后你合并两个，你想要的真正合并：

  m
 / \
*   *
|   |
*   *
| M |       <-- this is the one you want to disregard
|/ \|
*   *
|   |
*   *
|   |

然后你可以做一个空合并来摆脱悬空头。不幸的是，除了通过TortoiseHg，我不知道怎么做。它有一个复选框，我可以从其中一个分支中丢弃更改。

使用TortoiseHg，我会更新到我想要保留的合并（最上面的小写m），然后选择并右键单击下面的悬空合并头，然后选中“放弃合并目标的所有更改（其他）修订“：

Answer 2

  

我们做了'hg backout'的实验，退出合并（不确定这是正确的方法）。然后从默认情况下删除branch1中的更改​​，这很好 - 但我们不能用branch1重新合并。

我使用backout进行合并取消。你不能重新合并，但你可以“退出退出合并”，即当你想要重新合并时，你在“支持合并变更集...”提交'hg backout'，然后再次合并分支。

示例：

  7     M       remerge
  6   /   \
  5   *   |     hg backout 3 (backout backout)
  4   |   *     fix error 
  3   *   |     hg backout 2
  2   M   |     fail merge
    /     \
  1 *     *
    |     |

Answer 3

感谢大家的大力投入！由于我们急于解决问题，而且我们的团队对Mercurial来说相对较新，我们使用了非常实用的解决方案。

在我们的存储库服务器上，我们创建了一个新的存储库，然后我们克隆了旧的存储库，直到合并之前的版本。然后将新克隆推送到服务器并向所有人发送新链接。幸运的是，我们是一个非常小的开发团队。

也许不是解决问题最合适的方式，但它有效：）

Answer 4

你无法真正退出合并。 IMO，处理这个问题的最好方法就是放弃合并并继续合并之前的变更集，留下悬空头（可以剥离）。如果自合并以来发生了其他变化，他们可以重新定位到新的“好”头上。

Answer 5

此答案假设您已经推送

这将导致（至少一个）未解决的头部，这取决于您刚忘记的内容。更多取决于谁从哪个分支推出。

我喜欢HG并且狂热地使用它，但是他们对分支的想法可以在与（通过设计）故意不可变的历史相结合的情况下驱动某人。

出于这个原因，我通常在进行分支合并之前克隆repo的备份（本地）。我总是在拉前检查。

Eric Raymond is working on something或多或少是DVCS不可知的，可以（希望）帮助你所描述的oops，但我不认为他会在一周内完全实施HG支持或二。不过，它可能值得一看。

但是，只有在没有人拉出'ooopsie'小费的情况下才有用。

Answer 6

我有这个问题。当同事仍然不完整时，同事意外地将我的分支合并到默认分支。最初我刚刚退出合并，这似乎工作正常，直到我想将我的分支合并为默认保持。我需要的文件在合并时被标记为删除。

解决方案是一直回到我原来的后退，修复了我的同事的错误并退回了。这会阻止文件被标记为已删除，让我成功将我的分支合并为默认值。