好的 - 当我使用它时，我肯定会越来越多地了解Mercurial和版本控制系统，但我真的很困惑为什么我的一个存储库的本地副本（称之为project-alpha）我使用的三台机器（机器1，机器2和机器3）是不同的。值得注意的是，他们没有共享相同的提示。
我希望有人可以向我解释这个问题，并且还提供一些解释，说明如何避免必须完全“合并”分支（这就是首先出现这种复杂情况的原因）。如果有人可以提供一个例子来说明某些情况会迫使我在一台机器上“合并”，那将是非常棒的，而在另一台机器上则完全没问题。
为了澄清，我包括
hg log --graph
我正在使用的三台机器中的每一台机器的命令（但只有它们开始不同的地方，因为它是我正在研究的一个长项目）。
计算机1
@ changeset: 88:e8aafce5753a
| tag: tip
| user: Your Name <>
| date: Mon Jan 06 15:30:15 2014 -0500
| summary:
|
o changeset: 87:5d76250aad71
| user: Your Name <>
| date: Mon Jan 06 11:32:53 2014 -0500
| summary:
|
o changeset: 86:4788926f4dc9
|\ parent: 84:caf2a2a127e0
| | parent: 85:682beb5c2a22
| | user: Your Name <>
| | date: Thu Jan 02 12:52:17 2014 -0500
| | summary:
| |
| o changeset: 85:682beb5c2a22
| | parent: 83:bde4e46678d8
| | user: Your Name <>
| | date: Thu Jan 02 12:38:45 2014 -0500
| | summary:
| |
o | changeset: 84:caf2a2a127e0
| | parent: 82:729da698a926
| | user: Your Name <>
| | date: Tue Dec 17 15:44:17 2013 -0500
| | summary:
| |
| o changeset: 83:bde4e46678d8
|/ user: Your Name <>
| date: Wed Jan 01 22:20:54 2014 -0500
| summary:
|
o changeset: 82:729da698a926
| user: Your Name <>
| date: Mon Dec 16 12:41:54 2013 -0500
| summary:
机器2
@ changeset: 88:e8aafce5753a
| tag: tip
| user: Your Name <>
| date: Mon Jan 06 15:30:15 2014 -0500
| summary:
|
o changeset: 87:5d76250aad71
| user: Your Name <>
| date: Mon Jan 06 11:32:53 2014 -0500
| summary:
|
o changeset: 86:4788926f4dc9
|\ parent: 83:caf2a2a127e0
| | parent: 85:682beb5c2a22
| | user: Your Name <>
| | date: Thu Jan 02 12:52:17 2014 -0500
| | summary:
| |
| o changeset: 85:682beb5c2a22
| | user: Your Name <>
| | date: Thu Jan 02 12:38:45 2014 -0500
| | summary:
| |
| o changeset: 84:bde4e46678d8
| | parent: 82:729da698a926
| | user: Your Name <>
| | date: Wed Jan 01 22:20:54 2014 -0500
| | summary:
| |
o | changeset: 83:caf2a2a127e0
|/ user: Your Name <>
| date: Tue Dec 17 15:44:17 2013 -0500
| summary:
|
o changeset: 82:729da698a926
| user: Your Name <>
| date: Mon Dec 16 12:41:54 2013 -0500
| summary:
机器3
o changeset: 89:e8aafce5753a
| tag: tip
| user: Your Name <>
| date: Mon Jan 06 15:30:15 2014 -0500
| summary:
|
o changeset: 88:5d76250aad71
| user: Your Name <>
| date: Mon Jan 06 11:32:53 2014 -0500
| summary:
|
o changeset: 87:4788926f4dc9
|\ parent: 83:caf2a2a127e0
| | parent: 85:682beb5c2a22
| | user: Your Name <>
| | date: Thu Jan 02 12:52:17 2014 -0500
| | summary:
| |
+---@ changeset: 86:eab05f7f7ab6
| |/ parent: 83:caf2a2a127e0
| | parent: 85:682beb5c2a22
| | user: Your Name <>
| | date: Thu Jan 02 12:52:31 2014 -0500
| | summary:
| |
| o changeset: 85:682beb5c2a22
| | user: Your Name <>
| | date: Thu Jan 02 12:38:45 2014 -0500
| | summary:
| |
| o changeset: 84:bde4e46678d8
| | parent: 82:729da698a926
| | user: Your Name <>
| | date: Wed Jan 01 22:20:54 2014 -0500
| | summary:
| |
o | changeset: 83:caf2a2a127e0
|/ user: Your Name <>
| date: Tue Dec 17 15:44:17 2013 -0500
| summary:
|
o changeset: 82:729da698a926
| user: Your Name <>
| date: Mon Dec 16 12:41:54 2013 -0500
| summary:
首先我要说的是，我理解存在一些差异仅仅是因为某些机器上的某些更改被推到了其他机器上。机器1和2是我使用的主要机器，它显然没有太大差别。我关心的是Machine 3，它目前有3个头，还有一个额外的变更集（89而不是88）。我对发生了什么感到困惑，我怎么能解决这个问题，我很想知道我做了什么导致这一点，以便下次我可以避免这种行为。提前谢谢！
答案 0 :(得分：3)
请勿将hg编号与更改的实际版本号混淆。 （即，在一个回购中更改88与在另一个回购中更改88不同，除非他们 具有相同的签名代码。日志编号是用于在单个仓库中引用变更集的便捷捷径，但不会在回购中进行转换）。
如果您有3个不同的存储库，那么几乎不可能避免合并。通常，hg在自动合并方面做得很合理。如果你设置一个像样的hgmerge来使用你最喜欢的3路差异设置，甚至是偶尔的手册 合并不是那么痛苦。
但是，如果你想尽可能避免合并，你需要选择一个存储库作为“主要”仓库，并从主仓库中获取另一个仓库推送和拉动。
二级仓库的任何工作的第一步是同步到主仓库。
hg pull -u
您提交的任何更改都必须与主仓库上的提示相关，否则您将创建一个需要合并的分支，以便对主仓库进行更改。
hg incoming
对于监控远程回购的状态非常有用。
使用分布式版本控制系统的一个主要原因是它使合并更加痛苦。合并只是“标准”工作流程的一部分，如果您提交和同步，合并通常不会是一个问题。
答案 1 :(得分：3)
我只在机器3上看到一个额外的头，即变更集86:eab05f7f7ab6。
这是多余的变更集，您可以注意到它与常见的变更集4788926f4dc9具有完全相同的父级。
所以我猜它来自于机器3上明确完成的合并，然后拉动已经包含合并的仓库（在几秒钟前在另一台机器上请求！）。
这回答了你的一个问题：一旦你合并了一个回购，你就不需要（也不应该）在其他回购上再做一次。任何重复的任务都是可疑的，并且会破坏VCS的目的。
您可以通过以下方式减少分支，从而减少合并的需要：
hg pull -u）。最后的建议，您必须提供提交消息，并阅读两次半this smooth tutotial