水銀簡單的例子

Question

可能重複：
Introduction to Mercurial

我最近的變化是微乎其微。我最終做對了嗎？

$ hg pull 
warning: code.google.com certificate with fingerprint d2:33:75:af:62:64:5b:75:dc:3f:bf:22:30:b6:27:13:ff:3f:90:fd not verified (check hostfingerprints or web.cacerts config setting) 
pulling from https://niklasro@code.google.com/p/montao/ 
searching for changes 
adding changesets 
adding manifests 
adding file changes 
added 1 changesets with 1 changes to 1 files 
(run 'hg update' to get a working copy) 
ubuntu@ubuntu:/media/Lexar/montao$ hg update 
1 files updated, 0 files merged, 0 files removed, 0 files unresolved 

所以我不應該做合併，我應該拉？

爲什麼沒有簡單的例子說明2個開發人員如何協作？

例如

Time  Developer 1    Developer 2 
       hg clone     hg clone 
       editing 
       hg commit 
       hg push 
             editing 
             hg pull 
             hg commit 
             hg push 

2個開發商像上面之間的工作流程的一個例子將使它更容易理解什麼是汞拉，MERG，更新，而不是讓我迷惑拉與合併。

例如，我現在知道如何從另一個地方發生變化時不能得到2個頭。

我可能需要一個例子說明2個開發人員如何協作以及如何獲得遠程更改。

Answer 1

有關如何使用水銀和其他一些VCS我們看看埃裏克庫的Version Control by Example偉大的深入的示例或Joel Spolsky的hginit.com（我的答案是否會自動降低上市Joel第二？）

Answer 2

如果鍵入hg help pull

它顯示：

pull changes from the specified source 

    Pull changes from a remote repository to a local one. 

所以這是RemoteRepository->本地庫操作。與您當地的工作目錄無關。

如果你鍵入「汞幫助合併」

merge working directory with another revision 

    The current working directory is updated with all changes made in the requested revision since the last common predecessor revision. 

碰巧你的本地庫和本地工作副本之間。與遠程回購無關。

如果你要求的例子/手冊，網上有很多。我列出一些在這裏，希望它對你有幫助。

http://hgbook.red-bean.com/read/a-tour-of-mercurial-merging-work.html
http://www.rutherfurd.net/2010/apr/22/merging-mercurial-example/
https://www.mercurial-scm.org/wiki/TutorialMerge

Answer 3

基本概念

拉帶來了其他開發商的新的變更到自己的倉庫。這可能會引入一個新的頭，它會這樣說，如果它。

合併將兩個頭合爲一體。如果不超過1個頭，則不需要合併。

更新在修訂之間切換，例如，從當前正在進行的工作版本轉換爲剛剛插入的版本。如果您有本地未提交的更改，則更新將嘗試通過執行未跟蹤合併來合併它們。

不管你更新還是合併後都取決於拉是否引入了新頭。

簡單的兩開發商的工作流程

最簡單基本的當兩個開發者之間的直接合作的工作流程是：

1. hg pull otherdev
2. hg update或hg merge
3. 編輯
4. hg commit -m "testing..."

pull + update（簡寫：pull -u）確保您開始使用最新版本的代碼。如果你的同事在你最後一次提交和提交之間做出任何改變，這會告訴你它引入了一個新的頭，你需要合併。你不必總是拉，你也可以跳過它，只需編輯，提交，編輯，提交（...）一段時間;如果你正在做某件事而不想擾亂你的流量，那麼就等待拉動和合並，直到你準備好了（但我至少每天要做一次）。

一般而言，您不應將更改推送給您的同事;通過這種方式，您可以控制存儲庫中的內容，並且不會因突然出現的新變更集而感到困惑。

注意：通過在步驟3和步驟4之間更新，您可以減少創建分支分支的可能性，在SVN中，這是您不得不做的。不過，我會建議對這種做法，因爲如果存在衝突，它會使您的更改處於故障狀態，並且在修復它之前您將無法提交它。 DVCS的一大優勢就是，即您可以避免這種情況，並在不必擔心合併之前安全地提交您的工作代碼。

改進兩開發商的工作流程

爲了改善這種工作流程，我真的建議創建第三，共享回購爲您和您的同事作爲中間使用，而不是從海誓山盟直接拉動。

這引入了一個額外的push步驟，但好處在於，您可以進行一堆提交，並自己決定何時可以通過推送與您的同事共享您的更改。這減少了測試所需的時間，浪費你的同事的時間，因爲你不小心弄壞了東西，他把它的可能性。