这不是一个正常的工作流程吗？为什么需要新分支标志？
[default] $ hg branch foo
[foo] $ [... some commits ...]
[foo] $ hg update default
[default] $ hg merge foo
[default] $ hg commit -m "merged foo"
[default] $ hg push
abort: push creates new remote branches: foo!
(use 'hg push --new-branch' to create new remote branches)
什么是另一种理想的方式做分支→合并→推？
mercurial哲学是，你不应该推动使其他用户更难的东西。与这个问题相关的是，多个头对其他开发者来说更难，因为他们需要合并你的更改。因此，默认情况下推送新的头部会被服务器拒绝。 -f选项用于推动新的头部。
但是，推新命名分支的情况在概念上与在同一分支上推新头的情况完全不同。许多工作流程（包括我的）都在单独的命名分支上完成每项任务。 --new-branch选项允许您推出新分行，同时拒绝现有分行的新行长。它也不同（正如你所看到的），因为即使新分支没有创建新的头部（由于合并）也需要它。
我个人的感觉是，默认情况下应该允许新的分支，但是mercurial开发者更喜欢其他方式。
这是一次性的事情。第一次使用--new-branch时，只需使用（新）分支。这是正常的。
每隔一个按钮可以保持为hg push，否则为--new-branch标志。
如果我在执行一个''--close-branch''来删除命名分支，该怎么办？我不应该得到这个放弃，那不是吗？它现在发生在我身上。 –
这取决于分支的用途。
是否在自己的存储库克隆中内部使用，只要您的功能与其他功能分离开发，就可以将更改提交到分支。
后，你完成，你就必须投入一些工作要跟踪谁可能做了默认分支
那么你应该在他们的变化更新改变其他人的努力，解决冲突的承诺部分。 切换到默认值，并通过合并您的更改使您的功能成为默认分支的一部分。现在你可以关闭你的分支，提交并推送它！
我已经使用了两年*的hg，并且我不明白你的意思。你在回答这个问题吗？ –
推测性的，因为内部一个新的分支是一个新的头，和hg balks在发送新的头与-f（强制）选项。 –
即使您已将foo合并为默认值，您理解中的差距可能是Mercurial中的差异（与git不同），但仍会发送一些不可变分支属性为“foo”的变更集。在git中，foo这个名字永远不会用这些命令逃离你的本地系统，但是在Mercurial中，如果你想要这种行为，你可以使用书签而不是命名分支。 –