使用Mercurial時的替代例程Hg

Question

在使用Mercurial時，我想就您應該使用哪種下面的例程或者哪些更適合使用這些例程。假設我有最新的代碼。
首先程序如下：

1. 做，如果
2. hg commit
3. 重複步驟1和2需要我的工作
4. 當我準備推我hg pull，hg update
5. hg merge，hg commit
6. hg push

二是：

1. 做我的工作
2. 當我準備好提交我hg pull，hg update
3. hg commit，hg push

的事情是，就我知道第一種選擇是大多數開發人員（應該）使用的選擇，因爲與第二種選擇不同，它提供了使用本地存儲庫，因爲這對DVCS來說是正常的事情。

我的同事們鼓勵我使用第二種方式，因爲這樣我就避免了分支和後來可能出現的合併問題（因爲在過去，他們有這樣的問題），所以我留在幹線發展線上。 我想第一個選擇是應該更好的選項，因爲合併是DVCS中不應該害怕的事情，與CVCS不同，它使我有機會使用本地存儲庫。

Answer 1

沒有在工作的任何區別，你會在兩種情況下可以做：用第一個工作流

• ，你將在第5步中做了合併。

• 與第二個工作流，你做同樣的合併作爲更新的一部分，在步驟2中

第一個工作流的感覺更安全了許多，因爲你的工作已經承諾的工作。這意味着，如果合併結果變得複雜，則返回到乾淨狀態是很簡單的：hg update -C .。

但是，即使使用第二個工作流程，您實際上也可以獲得原始文件：hg resolve --all --tool internal:local將重新開始hg update合併，併爲所有文件選擇原始版本。

真正的區別在於第一個工作流程更好地顯示了實際發生的情況。通過該工作流程，您可以以更小更合乎邏輯的步驟呈現您的更改。當你的大學試圖理解你所做的事情（代碼評論）和未來的調試（hg bisect）時，這會有很大的幫助。

您可以通過hg rebase得到兩全其美的效果。這可以讓你做出小而合乎邏輯的提交，然後最終將這些提交移到學院完成的工作之上。在那種情況下，不會出現合併變更集合 - 豐富而豐富的線性歷史記錄。

所以，如果你有拉後這段歷史：

... [a] --- [b] --- [x] --- [y] --- [z] 
       \ 
       [d] --- [e] 

，你必須創建x到z，那麼一個正常的合併將創造這段歷史：

... [a] --- [b] --- [x] --- [y] --- [z] 
       \      \ 
       [d] --- [e] ----------- [f] 

和您衍合

... [a] --- [b] --- [d] --- [e] --- [x'] --- [y'] --- [z'] 

其中x'到z'是x到z（不同的變更集ID，因爲它們具有不同的祖先）的重定版本。

我一直使用這樣的rebase，我覺得它給出了最好的整體歷史。請記住，不要變更已經公開的變更集：變更會修改變更集，但是如果變更集已經公開，那麼您很難修改其他副本。結果是重複的變更和混淆。

Answer 2

基本上，你已經回答了這個問題自己：

第一個例程是「默認」一個DVCS，因爲它需要典型的DVCS的優勢功能
（本地資源庫，更快的承諾，因爲沒有網絡參與，因爲許多小的提交比較少的大提交更詳細的歷史...）

使用第二個例程不是「錯誤」或「不好」，但你必須意識到你使用的事實一個DVCS好像它是一個CVCS，所以你故意選擇不使用DVCS的一些優點（見上文）。

長期CVCS用戶（可能像你的同事）的人往往更喜歡第二個例程，因爲他們感覺他們已經知道的更多。
另外，合併在DVCS中比CVCS更好地工作，所以他們的「可能的合併問題」參數可能僅僅是因爲他們過去在CVCS中有問題，並且假定它在DVCS中是相同的（事實並非如此）。