这不是一个正常的工作流程吗？
[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)
进行分支→合并→推送的理想方式是什么？
答案 0 :(得分：6)
多变的哲学是你不应该推动使存储库的其他用户更难的东西。与此问题相关的是，多个头部使其他开发人员更难，因为他们需要合并您的更改。因此，默认情况下，服务器会拒绝推送新头。 -f选项用于推动新头。
然而，推动新命名分支的情况在概念上与在同一分支上推动新头部完全不同。许多工作流程（包括我的）在单独的命名分支上执行每项任务。 --new-branch选项允许您推高新分支，同时拒绝现有分支上的新头。它也是不同的（正如你所见），因为即使新分支没有创建新的头部（由于合并），它也是必需的。
我个人认为默认情况下应该允许新的分支，但是mercurial开发者更喜欢。
答案 1 :(得分：3)
这是一次性的事情。只需在第一次推送（新）分支时使用--new-branch。这很正常。
其他每次推送都可以保留为hg push，没有--new-branch标记。
答案 2 :(得分：0)
这取决于分支的用途。
它是否在您自己的存储库克隆内部使用，只要您开发与其他功能分离的功能，就可以将更改提交到分支。
完成后你将不得不投入一些工作来跟踪其他可能在默认分支上做过更改的人的工作
然后你应该更新他们的更改，解决冲突提交你的部分。 切换到默认值并通过合并更改使您的功能成为默认分支的一部分。现在你可以关闭你的分支，提交东西并推送它！