在合并之前哪个头位置?
进行合并时有没有头可以选择?在合并之前哪个头位置?
我的意思是这样的:我已经说了旧的rev 1000.与此同时,我做了234次提交,并且我的转速为1234年。现在我需要回到1000年来为客户实现bug修复。我犯了错误修正,给客户发布,并且提交1235.
这只是一个微小的改变:只影响一个文件。
在这一点上我有两个头:1235(其母公司为1000)和1234他们的共同(盛大隆重-...-父)是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
的输出似乎取决于我目前的头部。
这是正常的行为,如果是的话,是否有一个头比另一头“偏好”?
这两个操作的结果是在同一个存储库/源代码状态吗?
是的,它们都导致相同的最终状态。 Mercurial中的合并几乎是100%对称的。唯一的非对称部分是命名分支:
hg update branch-a
hg merge branch-b
hg commit
将在branch-a
创建变更。首先更新到branch-b
将在branch-b
上创建它。尽管如此,您可以在提交之前通过发布hg branch
来更改合并提交的分支,因此默认分支名称更像是一个建议。
然而,在你的情况下,我肯定会更新回修订版1234,然后将修补程序合并到此版本中。他们的方式我想这是你有一个主要的开发线 - 这是你在为下一个版本开发新功能的地方。
当您对旧版本进行错误更新时,请更新回来,进行错误修复,然后为您的客户制作错误修复版本。然后,您为bug修复创建了另一个(微小)分支。合并之前要更新到何处的问题是:
我想继续沿着bugfix分支吗?如果是这样,那么留在bugfix并将主分支合并到它。
我想继续沿主分支吗?如果是,则更新回主分支并将bugfix分支合并到其中。
在这种情况下,只更新回主分支 - 您希望将bug修复与新功能一起使用,并且您希望添加更多功能。
想想我上面提到的命名分支 - 那里你会做
hg update 1.x
# fix bug
hg commit
hg tag 1.3
回去1.x的系列软件的,修正错误,并进行了1.3修正版。完成后,您想要与default
分支合并。由于分支名称是从合并的第一父继承,这是最顺利更新第一默认:
hg update default
hg merge 1.x
hg commit
这就是recommended way做的水银。
+1,非常感谢。我确实回到了开发的主线,并将bug修复合并到了那里。但是我感到非常惊讶:*“hg status”*(我在做提交之前总是运行* hg sta *)让我感到困惑......所以我有点“推断”它可能更好地更新到主线,从那里合并。但是,我仍然想确定我没有看到任何东西。不知何故,我始终确信,合并总是100%相同。我不知道我从哪里得到这个信息:它对我来说似乎是合乎逻辑的......但是我错了:)感谢您的链接,时间阅读! – NoozNooz42 2012-01-17 22:08:58