我如何退出Mercurial的合并，然后与该分支重新合并？
我有两个分支，默认和分支1。 我们团队中的一个人错误地将branch1与默认值合并在一起。 branch1中的内容还没有准备好与默认合并（它包含了对构build和部署环境的重大修改）。
我们做了一个'hg backout'的实验，支持合并（不确定这是否正确）。 然后，从branch1的更改被删除默认情况下，这是很好的 – 但我们不能与branch1重新合并。
我们应该如何解决这个问题？
在这里有许多情况下，你可能想要做到这一点，我会让每个场景的标题，以便您可以find适合您的情况。 请注意，我还在学习Mercurial，如果我所说的是错误的，使用错误的术语，可以做得更好等等，我会喜欢指针。
没有进一步的变化，合并不共享（不推/拉）
程序员已经合并，但没有做任何其他事情，也没有以任何方式与任何人分享改变
在这种情况下，只需放弃本地克隆，并从安全的存储库中获取新的克隆。
合并之上的本地更改，不共享
程序员已经合并，并继续工作的基础上合并。 合并后的变更集应该保留，但合并本身应该被删除。 没有与任何人共享的变化（合并+下面的变更集）
在这种情况下，我会做四个之一：
- 尝试使用REBASE扩展名，这将把变更集从一个位置移动到另一个位置。 如果变更集是基于合并引入的代码更改，则必须执行一些手动工作来调和差异。
- 尝试使用MQ扩展来将要保留的变更集拉入修补程序队列，然后将其推回到其他位置。 然而，这将会与基于合并的改变的REBASE扩展具有相同的问题
- 尝试使用TRANSPLANT扩展名将更改从一个位置“复制”到另一个位置。 尽pipe如此，还是存在与前两个相同的问题。
- 再次进行这项工作，可能需要借助差异工具来对我想丢弃的变更集进行修改，然后在正确的位置重新进行修改。
要摆脱合并变更集+以下所有变更集，有几个选项：
-
在MQ扩展中使用strip命令
hg strip <hash of merge changeset> -
克隆并拉，并指定导致的变更集的散列，但不包括合并。 从本质上讲，通过从被破坏的克隆中提取一个新的克隆来创build一个新的克隆，并且避免引入你不想要的合并。
hg clone damaged -r <hash of first parent> . hg pull damaged -r <hash of second parent>
合并推送给其他人，控制克隆
程序员已经推到了主存储库，或者其他人，或者从程序员存储库中取出的人。 但是，您（如开发人员小组）可以控制所有存储库，因为您可以在完成更多工作之前联系并与所有人交谈
在这种情况下，我会看到第一步或第二步是否可以完成，但是可能要在很多地方完成，所以这可能涉及很多工作。
如果没有人根据合并变更集完成工作，我将使用步骤1或2进行清理，然后推送到主存储库，并要求每个人从主存储库获取新的克隆。
合并推动，你无法控制克隆
程序员推送了合并集，而且你不知道谁将有合并变更集。 换句话说，如果你成功地从你的仓库中消除它，那么一个仍然拥有它的人的stream浪将会把它带回来。
忽略合并变更集并在两个分支中工作，就好像它从未发生过一样。 这将留下一个摇摇欲坠的头。 之后你可以在合并两个分支的时候，对这个头进行一个空归并来摆脱它。
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，我不知道该怎么做。 它有一个checkbox，我可以放弃其中一个分支的更改。
用TortoiseHg，我会更新到我想要保留的合并（最上面的，小写的m），然后select并右键点击下面的悬挂合并头，然后检查“放弃合并目标（其他）修订版的所有更改” ： 
我们做了一个'hg backout'的实验，支持合并（不确定这是否正确）。 然后，从branch1的更改被删除默认情况下，这是很好的 – 但我们不能与branch1重新合并。
我使用退出合并取消。 你不能重新合并，但你可以“退出退出合并”，也就是说，当你想重新合并时，你可以在“退出合并变更集”提交'hg backout'，然后再次合并分支。
例：
7 M remerge 6 / \ 5 * | hg backout 3 (backout backout) 4 | * fix error 3 * | hg backout 2 2 M | fail merge / \ 1 * * | |
你不能真正退出一个合并。 国际海事组织，处理这个问题的最好办法就是放弃合并，继续合并之前的一系列变革，留下一个悬而未决的头（可以剥离）。 如果合并以后发生其他变化，可以重新装上新的“好”头。
这个答案假设你已经推了
这将导致（至less一个）未解决的头部，这取决于你刚刚忘了什么。 更多取决于谁从什么分支推。
我喜欢HG并且很热情地使用它，但是当他们的历史是（有意devise的）故意不可改变的时候，他们的分支想法可能会让某个人变得疯狂。
我通常在进行分支合并之前克隆一个备份（本地）的回购，正是因为这个原因。 我总是在拉之前检查。
Eric Raymond 正在做一些或多或less的DVCS不可知论的事情，可以（希望）像你描述的哎呦一样帮助你，但是我不认为他会在一两个星期内完全实施HG支持。 不过，这可能值得一看。
但是，只有在没有人提出'ooopsie'的提示时才有用。
感谢大家的好评！ 由于我们急于解决问题，而我们这个小组对于Mercurial来说是比较新的，所以我们用了一个非常实用的解决scheme。
在我们的版本库服务器上，我们创build了一个新的版本库，然后我们克隆了旧的版本库，直到合并之前的版本。 然后将新的克隆推送到服务器，并将新的链接发送给每个人。 幸运的是，我们是一个相当小的开发团队。
也许不是解决问题的最合理的方式，但它的工作:)
我有这个确切的问题。 一个同事不小心将我的分支合并到默认分支中，但仍然不完整。 最初我刚刚退出合并似乎工作正常，直到我想合并我的分支默认保持。 我需要的文件在合并时被标记为删除。
解决的办法是一路回到我原来的状态，解决了我同事的错误，然后退出。 这阻止了文件被标记为已删除，让我成功地将我的分支合并到默认。
