在进行合并之前要先定位哪个？

Question

合并时是否有偏头？

我的意思是这样的:比如说,我有旧的1000转.同时我做了234次提交,我的转速是1234.现在我需要回到1000转,为客户实施错误修正.我提交了错误修正,将发布给客户,并提交了1235.

这只是一个微小的变化:仅影响一个文件.

在这一点上,我有两个脑袋:1235(父母是1000)和1234.他们的共同(grand-grand -...- parent)是1000.

如果我发出一个hg merge后跟一个hg status,我收到一个巨大的变化列表.

但是,如果我先做hg update -C 1234,然后是a hg merge和a 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在合并两个相同的头之后询问status(),但输出hg status似乎取决于我目前所处的头部.

这是正常的行为,如果是的话,是否有一个人比另一个更"偏好"？

这两个操作最终会导致相同的存储库/源代码状态吗？

Answer 1

是的,它们都导致相同的最终状态.Mercurial中的合并几乎是100%对称的.唯一的非对称部分是命名分支:

hg update branch-a
hg merge branch-b
hg commit

将创建一个变更集branch-a.更新到branch-b第一个将创建它branch-b.但是,您可以在提交hg branch之前通过发出更改合并提交的分支,因此默认分支名称更像是建议.

但是,在您的情况下,我肯定会更新回修订版1234,然后将错误修复程序合并到此修订版中.他们的方式我认为你有一个主要的开发线 - 这是你正在为下一个版本开发新功能的地方.

当您对旧版本进行错误修复时,请更新回来,制作修正错误,并向客户发布错误修正版本.然后,您为错误修复创建了另一个(微小的)分支.关于合并之前的更新位置的问题现在是这样的:

在这种情况下,只有更新回主分支才有意义 - 您希望将错误修复与新功能一起使用,并且您希望添加更多功能.

想想我上面提到的命名分支 - 你会做的

hg update 1.x
# fix bug
hg commit
hg tag 1.3

回到你的软件的1.x系列,修复bug,并发布1.3 bugfix.完成后,您想要与default分支合并.由于分支名称是从合并中的第一个父级继承的,因此最顺利地更新为默认值:

hg update default
hg merge 1.x
hg commit

这是在Mercurial中推荐的方法.