15個開發者團隊的良好Mercurial工作流程

Question

我現在正在使用Allfusion Harvest的15位開發團隊中。由於可用的前端TortoiseHg和MercurialEclipse，我們對此並不滿意，並且四處尋找我們已決定切換到Mercurial。

我們目前正在使用一個十二年前的Harvest版本，我發現我們目前的工作流很難轉化爲Mercurial。我與ClearCase以往的經驗，我們使用了類似的模式：

A A A 
| | | 
B C | 
| /| | 
C | E 
| |/ 
D E 
|/
E 

其中左主幹是不穩定，中間是測試和右邊是穩定。現在我沒有任何問題在Mercurial中重新創建這個分支模型（在一箇中央存儲庫中）。這個想法是，開發人員然後克隆這個存儲庫，從分支不穩定，做他們的工作，然後合併不穩定。在網上閱讀我還沒有看到Mercurial工作流程針對的團隊多於三名開發人員，因此我不確定這是否是一個好的工作流程。

所以兩個問題：

這是一個良好的工作模式？

您如何與Mercurial合作以及您的團隊中有多少人？

編輯：由於問這個問題，我已經使用Gitflow和Github flow。根據發佈複雜性和團隊規模，兩者都很有用。當使用Mercurial時，我已經停止使用分支（除穩定/不穩定外），而是使用受Git影響的書籤。

Answer 1

在Fog Creek，我們使用類似的工作流程，但有一個主要區別。由於在Mercurial中並沒有真正輕量級的分支（即使合併後命名分支保留其名稱），我們傾向於爲我們的分支使用多個存儲庫。我發現這樣可以更容易地知道您正在處理的是哪個分支，並且還會使分支之間意外合併變得更加困難，因爲您的每個分支都可能擁有自己的臨時分支。

取而代之的是，我們使用了Stable，QA和Devel回購協議。特性工作進入Devel併合併到QA和Stable，而錯誤修復進入Stable和QA，併合並回Devel。

很多我們的開發人員也爲自己的分支機構保留更長時間運行的項目，或者他們正在開發的任何項目可能會破壞別人的代碼。

我們的一些開發人員將每個分支放在不同的目錄中，因此他們明確地從一個切換到另一個。其他人則傾向於將所有三個合併爲一個回購，使用remote-branches擴展來管理各種頭部。

當我們使用基本的hg serve來承載我們的回購時，這確實給了我們一些麻煩，因爲創建新的回購回購或重命名回購需要系統管理員。這是我們做到這一點的原因之一，因此任何人都可以在Kiln中創建分支回購。

如果Mercurial有一個更好的分支模型，並且有一些工作可以幫助解決這個問題，但這對我們很有用。

Answer 2

• 就我所知，您的工作流程相當好。