这里有很多场景,你可能想这样做,我会把每个场景作为一个标题,这样你就可以找到适合你的情况的场景。请注意,我仍在学习反复无常,如果我说的是错误的,使用错误的术语,可以做得更好,等等,我想要指针。

无进一步更改,合并不共享(无推/拉)

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

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

合并顶部的本地更改,不共享

程序员已经合并,并在合并的基础上继续工作。合并后的变更集应保留,但合并本身应被删除。更改(合并+以下更改集)尚未与任何人共享

在这种情况下,我将执行以下四种操作之一:

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

要除去合并变更集+以下所有变更集,有两个选项:

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,我将更新到要保留的合并(最上面的小写m),然后选择并右键单击下面悬挂的合并头,然后选中“放弃来自合并目标(其他)修订版的所有更改”:

我们做了一个“hg backout”的实验,退出合并(不确定这是正确的方法)。然后,来自branch1的更改在默认情况下被删除,这很好——但是我们不能用branch1重新合并。

我使用backout取消合并。您不能重新合并,但您可以“回退合并”,即当您要重新合并时,您可以在“回退合并变更集…”上执行“hg回退”,提交,然后再次合并分支。

例子:

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

感谢大家的大力投入!由于我们有点急于解决问题,而且我们的团队对Mercurial还比较陌生,所以我们采用了非常务实的解决方案。

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

也许不是解决问题的最舒适的方法,但它奏效了:)

你不能很好地退出合并。在IMO看来,处理这一问题的最好方法就是放弃合并,继续合并前的一系列变更集,留下一个悬垂的头部(可以剥离)。如果合并后发生了其他更改,则可以将它们重新定位到新的“好”头上。

这个答案假设您已经

这将导致(至少一个)未解决的头,取决于你刚刚忘记了什么。更多的取决于是谁从哪个分支推出来的。

我喜欢HG,并且非常热衷于使用它,但是当他们的分支思想与(通过设计)故意不可变的历史结合在一起时,会让人抓狂。

我通常在进行分支合并之前(本地)克隆repo的备份,原因就在于此。我总是在拉之前检查一下。

埃里克·雷蒙德 is working on something 这或多或少是DVCS不可知论的,可以(希望)在像您描述的oops那样的情况下提供帮助,但我不认为他会在未来一两周内完全实现HG支持。不过,这也许值得一看。

但是,只有在没人给你小费的情况下才有用。

我有这个问题。一个同事不小心把我的分支合并到了默认分支中,但它仍然不完整。最初,我只是退出了合并,这似乎工作良好,直到我想合并我的分支到默认值保持。我需要的文件在合并时被标记为删除。

解决方法是一路回到我原来的“后退”模式,它修复了我同事的错误,然后又“后退”了。这阻止了文件被标记为已删除,并使我成功地将分支合并为默认值。