我们目前正在开发应用程序的新版本（版本2.0）。
我们有一位客户正在运行发现错误的应用版本1.0。我们更新了版本1.0的标记变更集，找到并修复了错误。
我们提交了在源代码树中创建新头的更改。
问题是如何最好地合并这个？理想情况下，我希望将其合并到1.0版之后的变更集中。我不想将它合并到提示中，因为发现错误的代码实际上不再存在。
我意识到我或许应该为“v1.0 bug fix”创建一个单独的分支。
谢谢， 本
答案 0 :(得分：2)
使用合并在存储库中移动更改时，所有关于您拥有更改的地点的最新共同祖先以及您想要的位置。如果在进行此修复之前，您的仓库看起来像这样：
[a]-[b]-[c]-[d]
1.0标记的变更集为[b]，那么您现在拥有：
[a]-[b]-[c]-[d]
\
-[e]
修正位于[e]。 如果就是这种情况，那么您只需要这样做：
hg update d
hg merge e
hg commit
然后你会有这个：
[a]-[b]-[c]-[d]-[f]
\ /
-[e]-----
如果另一方面，在进行更改之前，您的回购邮件如下所示：
[a]-[b]-[c]-[d]
\
-[e]-[f]
1.0抹布指向[f]然后你现在有了这个：
[a]-[b]-[c]-[d]
\
-[e]-[f]-[g]
使用[g]中的修复程序。如果您想将变更集[g]移至[d]而不将[e]和[f]与其一起移动，则无法做到这一点。您可以使用的不太好的方法（称为 cherrypicking ）是使用hg export和hg import命令。
没有工作流程需要樱桃采摘，但避免它需要一点预见。在第二种情况下，你可以通过不修复1.0系列（作为[f]的孩子）来避免它，而是作为你想要改变的两个地方的最近共同祖先的孩子。由于您希望在[d]和[f]中进行更改，因此您需要查找其最新的共同祖先并查看它[b]并使用这些命令将其作为子项进行更改：
hg update b
..edit..
hg commit
留下这张图：
[a]-[b]-[c]-[d]
\
\--[g]
\
-[e]-[f]
此修复程序，[g]是一个新头，您可以将其合并到[d]（2.0）和[f]（1.0）中，而不需要任何挑选。命令是：
hg update d
hg merge g
hg commit
hg update f
hg merge g
hg commit
，结果图表为：
[a]-[b]-[c]-[d]--[h]
\ /
\--[g]----
\ \
-[e]-[f]-[i]
其中[h]是您的新修补程序2.0，而[i]是您修复的新1.0。
总结：你可以随心所欲地避免采摘樱桃，但如果你不这样做，那就不是世界末日
答案 1 :(得分：1)
听起来你有这个：
[a]-[b]-[v1]-[c]-[d]-[v2]
\
-[fix]
并希望在不修复[修复]中的任何更改的情况下摆脱额外的头部。
以下命令将简单地标记分支关闭，并且它不会被视为额外的头部并且不会被hg heads和hg branches命令隐藏：
hg update fix
hg commit --close-branch -m "closed branch"
以下命令将“虚拟合并”额外的头部，丢掉任何更改。
hg update v2
hg --config ui.merge=internal:fail merge
hg revert --all --rev .
hg commit -m "dummy merge"
--config ui.merge=internal:fail标志阻止合并工具尝试合并任何冲突，但不会阻止添加到另一个头的文件出现，因为不会与新添加的文件发生合并冲突。 revert只会将所有文件更新回第一个父级状态。你最终会得到：
[a]-[b]-[v1]-[c]-[d]-[v2]-[merge]
\ /
-[fix]-----------
但[merge]的内容与[v2]相同。
进行虚拟合并的另一种方法是：
hg update v2
hg debugsetparents v2 fix
hg commit -m "dummy merge"
这将工作目录设置为v2，但随后“伪造”Mercurial，v2和fix都是父项，并将其作为合并提交。