這不是一個正常的工作流程嗎？爲什麼需要新分支標誌？
[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中，如果你想要這種行爲，你可以使用書籤而不是命名分支。 –