在我当前的工作流中，无论何时需要分支，我都使用书签，但为了从当前版本创建新头，我必须提交一些虚拟更改并返回一个修订，然后提交，否则无论我拥有多少书签，提交都会提交给同一个负责人。在mercurial中创建新头
例如，假设我在启40：
hg bookmark main
hg ci somefile -m 'dummy commit' # on rev 41 now
hg up -r 40
# make some changes
hg ci -A -m 'changes in bookmark' # created new head
hg bookmark test
这是常见的还是有一些shorcut给力新头的创造？
没有必要进行第二次头，在你的例子来创建，你不应该强迫它的创作。
与您的工作流程的好处是，你可以在功能test停止工作要做主枝上这样一个更迫切的变化：
> hg bookmark main
> hg bookmark test # Start work on feature test
... do some code ...
> hg commit -m "Working on feature test"
> hg update main # Stop working on test, start working on main
... do an urgent fix ...
> hg commit -m "Urgent fix"
> hg update test # Back to work on feature test
... do some more code ...
> hg update main # Finished the work so back to main
> hg merge test # Merge the work into main
> hg commit -m "Merge in feature test"
如果这样做了，你就已经完成了新功能，将它合并回主开发分支。
如果您在完成功能test的工作后未对main分支进行任何更改，则无法合并更改，因为无法将更改集合并为祖先，因此您需要移动在main书签到test书签如下：
> hg update test
> hg bookmark main -f
（我认为，这就是所谓的快进合并在git并且可以强制合并，如果你想，但没有mercurial相当于尽可能我知道）
我想你想练习nvie的工作流程，所以你想用--no-ff合并上游流。
据我所知，hg不支持在同一分支中与上游合并。正如这post所说，hg的头/书签是git't分支，而hg的分支是血统。
因此，解决方案是在分叉点，你改变书签和分支，然后你可以合并分支，因为它们是不同的血统。
在我的例子中，你可以很容易地hg branch -f dev，即使他们没有连接，重新打开分支。
所以，你可以有一个像分支：
然后书签应该是前缀为：
而且应该分出相应的分支机构。
然后，他们可以
我没有亢奋令人兴奋的，只是本地的，我使用书签来避免分支，只是测试一些变化。 – 2013-03-05 22:36:00
@dhunter对不起，误解了你的需求。是的，当'hg up BOOKMARK-NAME'时，书签将被激活。 – 2013-03-06 02:22:01
无需道歉，感谢您的关注。 – 2013-03-06 13:00:09
我明白了，但是当我创建两个书签并提交时，是将更改写入一个还是两个？ – 2013-03-05 22:39:13
明白了，它只是承诺活跃的书签，这正是我想要的，有太多过时的帖子“git vs mercurial”说旧的版本的东西，很难知道什么工作，直到你自己测试它。 – 2013-03-05 22:43:44