在合并时是否有首选？
我的意思是这样的：比如说，我有旧的1000转。同时我做了234次提交，我的转速为1234.现在我需要回到1000转，为客户实施错误修正。我提交了错误修正，将发布给客户，并提交了提交1235。
这只是一个微小的变化：仅影响一个文件。
此时我有两个脑袋：1235（父母是1000）和1234.他们的共同点（grand-grand -...- parent）是1000。
如果我发出hg merge后跟hg status，我会收到一个巨大的更改列表。
但是，如果我先执行hg update -C 1234，然后是hg merge和hg status，那么我只能看到我的独特变化（除非我误解了刚刚发生的事情）。
基本上，这样做：
hg update -C 1234
hg merge # (merging 1234 and 1235, my two only heads)
hg status
给出了与此不同的状态：
hg update -C 1235
hg merge # (merging 1234 and 1235, my two only heads)
hg status
所以基本上，我在合并两个相同的头之后询问状态（hg status），但hg status的输出似乎取决于我目前的头部。
这是正常的行为，如果是的话，是否有一个人比另一个更“偏好”？
两个操作结果都是在同一个存储库/源代码状态？
答案 0 :(得分：5)
是的，它们都会导致相同的最终状态。 Mercurial中的合并几乎是100％对称的。唯一的非对称部分是名为branches ：
hg update branch-a
hg merge branch-b
hg commit
将在branch-a上创建变更集。首先更新到branch-b将在branch-b上创建它。但是，您可以在提交之前通过发出hg branch来更改合并提交的分支，因此默认分支名称更像是建议。
但是，在您的情况下，我肯定会更新回修订版1234，然后将错误修正合并到此修订版中。他们的方式我认为你有一个主要的开发线 - 这是你正在为下一个版本开发新功能的地方。
当您对旧版本进行错误修正时，请更新回来，制作修正错误，并向客户发布错误修正版本。然后，您为错误修复创建了另一个（微小的）分支。关于合并之前的更新位置的问题现在是：
我想继续沿着bugfix分支吗？如果是这样，那么请留下错误修正并将主分支合并到其中。
我想继续沿着主要分支吗？如果是，则更新回主分支并将bugfix分支合并到其中。
在这种情况下，更新回主分支才有意义 - 您希望将错误修复与新功能一起使用，并且希望添加更多功能。
想想我上面提到的命名分支 - 你会做
hg update 1.x
# fix bug
hg commit
hg tag 1.3
回到你的软件的1.x系列，修复bug，然后发布1.3 bug修正版。完成后，您想要与default分支合并。由于分支名称是从合并中的第一个父级继承的，因此最顺利地更新为默认值：
hg update default
hg merge 1.x
hg commit
这是Mercurial中的recommended way。