我的團隊剛開始使用Mercurial和一箇中央存儲庫。我們有哈德森建立「默認」分支的一角 - 這基本上是我們的主線。我們有一個與我們的舊VCS的簽入政策，代碼審查，測試等必須在您登記到主線之前完成。約15位開發人員的Mercurial工作流程 - 我們是否應該使用命名分支？
所以，讓我們說你工作的特點X.你一些東西的工作，立足其關閉「默認」，然後您提交的部分功能作爲一個檢查點。當地你的「默認」現在已經被破壞 - 你還沒有與任何人分享，但是如果你要推動，那麼現在你已經在主線中破壞了代碼。
即使你等待推，直到你把一切都整理出來，好像在有些情況下你需要按一定的變化，但不是所有的（例如在上一次兩兩件事的工作）。
此外，如果你在你的所有檢查站檢查的變化，那麼就會出現在主線一些修改是建立，和其他主線不建。
我們已經開始使用命名的分支機構 - 但更多的閱讀我做的更多，我認爲我們是錯誤使用命名的分支。
如何建立一個良好的工作流程，使我們能夠運行哈德森和保持我們的主線政策有什麼建議？
您可能會考慮至少兩個存儲庫。 「主線」存儲庫具有經過測試和審查的代碼。代碼只有在Hudson經過測試後纔會被推送到這個存儲庫，並且在完成任何評估之後。 「測試」存儲庫將是主線的克隆。這是Hudson監視的存儲庫，所以無論何時將更改集推送到測試存儲庫，Hudson測試都是如此。如果測試通過，您可以設置Hudson構建步驟，將測試存儲庫中的更改推送到主線。
開發商總是推到測試庫，但主線只有拉，所以他們永遠只能拉測試代碼。如果他們需要分享未經測試的變更集，他們可以直接在彼此的本地存儲庫之間推/拉。也許可以配置Hg以便主線只接受來自測試存儲庫的推送，以便開發人員不會意外推送到主線而不是測試。
也可能有一個評論存儲庫。所以開發人員推動測試，哈德森推動測試代碼進行審查，然後審查代碼被推送到主線。
免責聲明：我只在平凡的項目和微不足道的方式上使用了Hg。
我們公司所做的是使用命名分支來區分穩定版本（我們只提交錯誤修復）和開發發生的下一個版本，我們定期將穩定版本修復爲默認版本（默認分支上有hg merge stable）。
對於代碼審查，我們使用mq擴展名使開發人員能夠提交乾淨的補丁。開發人員可以從各自的存儲庫中獲取信息，而不會污染參考存儲庫。
聲明：我們不使用哈德森。
這是一個心態問題。分佈式VCS不需要您保留單箇中央存儲庫。
與其讓主線開放給所有人檢查，設置它與有限的寫訪問。只有經過批准（測試，簽署，無論對您有意義的變更集）才納入主線。
你如何管理變更爲主線是一個廣泛的問題，有很多可能的答案。這裏有兩個我的頭頂：
首先，我強烈建議A Guide to Branching in Mercurial
接下來，你可以推只是當前分支：Nudge - A Gentler Version of Push
也許你可以決定只允許每個分支頭：32. Prevent a push that would create multiple heads
其他SO有關命名分支的問題：
謝謝，第一個鏈接很有幫助 - 以前沒見過。作者提到了我的一些同樣的擔憂，但似乎在命名分支中看到了好處。也許我可以用穩定/不穩定的想法來完成這項工作。 – 2010-03-01 10:38:42
你也可以考慮使用Bookmarks擴展而不是命名分支。
如果你熟悉git，書籤的行爲就像git-branches而不是mercurial分支。
我認爲這個策略甚至可以在單個回購協議內工作，但只是使用穩定和不穩定的分支。開發人員只承諾不穩定，一旦測試通過，它將合併到穩定。不得不通過更多的想法......但這是我不斷回頭的想法。 – 2010-03-01 10:41:06