5
在Mercurial上回退合并
您如何扭转合并对极化分支的影响而又不至于痛苦呢？ 这个问题困扰了我几个月，我终于放弃了。 您有1个存储库，其中有2个 命名分支。A和B。 A上发生的更改将不可避免地发生在B上。 直接在B上发生的更改绝不能在A上发生。 在这种配置中，将“ B”合并为“ A”会在存储库中产生可怕的问题，因为对B的所有更改都像在A中所做的一样出现在A中。 从这种情况中恢复的唯一“正常”方法似乎是“回退”合并，即： hg up -r A hg backout -r BadMergeRev --parent BadMergerevBeforeOnA 看起来一切正常，直到您决定以后以正确的方向合并，并且最终会发生各种令人讨厌的事情，并且在特定分支B上被擦除/注释掉的代码突然变得未擦除或未注释。 到目前为止，除了“让它做事，然后手动解决所有问题”之外，还没有可行的可行解决方案，而且说实话有点麻烦。 这是说明问题的图像： [原始图像丢失] 文件C和E（或更改C＆E）必须仅出现在分支b上，而不出现在分支a上。此处的修订版A9（分支a，修订版9）是问题的开始。 修订版A10和A11是“回退合并”和“合并回退”阶段。 修订版B12是无用的，错误地反复删除了原本不打算删除的更改。 这种困境造成了很多挫败感和蓝烟，我想结束这一困境。 注意 尝试通过钩子或策略来禁止反向合并可能是显而易见的答案，我发现将这种情况搞糟的能力相当高，而且发生这种可能性的可能性很大，以至于即使采取对策，您仍然必须假设不可避免地会发生这种情况，以便您可以在解决时解决它。 详细说明 在模型中，我使用了单独的文件。这些使问题听起来很简单。这些仅代表可以是单独一行的任意更改。 同样，为了增加伤害，在分支A上进行了实质性更改，留下了常设问题：“使分支A的更改与分支B的更改发生冲突，分支B的更改看起来像是在变回（并退出），看起来像是在更改”在分支A上，“ 关于历史重写技巧： 所有这些追溯解决方案的问题如下： 我们有9000次提交。 新鲜克隆因此需要半小时 如果某个地方甚至存在一个错误的存储库克隆，它的一种似然又会回到与原始存储库的联系，然后重新将其重新敲打。 每个人都已经克隆了该存储库，现在已经进行了几天提交了。 这样的一个克隆恰好是一个在线站点，因此“擦除该克隆并从头开始” =“ big nono” （我承认，以上许多内容有些愚蠢，但它们超出了我的控制范围）。 唯一可行的解决方案是那些假设人们可以并且将做错所有事情的解决方案，并且有一种方法可以“消除”这种错误。