如何在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进行清理，然后推送到主存储库，并要求每个人从主存储库中获取新的克隆。

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

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

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

  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

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

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

Answer 5

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

Answer 6

这个答案假定你已经推了

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

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

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

Eric Raymond 正在开发一种或多或少与DVCS无关的东西，可以（希望）帮助你所描述的oops，但我认为他不会在一两周内完全实现HG支持。 不过，它可能值得一看。

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