关于 TortoiseHg 的简单问题
假设一个人克隆了一个存储库，他的主要工作是在本地对其进行编辑。应该遵循什么正确的操作，以便他可以在保留更改的同时与初始上游合并？即像 TortoiseSVN 中的“更新”。
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
假设一个人克隆了一个存储库，他的主要工作是在本地对其进行编辑。应该遵循什么正确的操作，以便他可以在保留更改的同时与初始上游合并？即像 TortoiseSVN 中的“更新”。
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
接受 或继续使用网站，即表示您同意使用 Cookies 和您的相关数据。
发布评论
评论（3）
我看到了带有“mq”扩展名的第三个解决方案（“Mercurial Patch Queue”）。
使用这个你不会提交，而只是创建并进一步从本地更改刷新你的补丁。定期拉取之后并在更新工作副本之前，您将分离补丁、更新，然后重新附加补丁。
这样，您将在补丁队列中完全隔离地管理自己的更改，同时与世界的更改保持联系。
I see a third solution with the "mq" extension ("Mercurial Patch Queue").
Using this you wouldn't commit, but just create and furthermore refresh your patch(es) from your local changes. After pulling on a regular basis and prior to updating your working copy, you would detach your patch(es), update and then re-attach the patch(es).
This way you will manage your own changes completely isolated in the Patch Queue, while keeping on touch with the changes from the world.
简短的答案是“拉”。从那里，您有两个选择
您可以简单地更新，就像使用 svn 一样，并且您的更改将保留在本地且非版本化，或者您可以提交更改并将其与您拉出的头合并。如果您不推迟，这些合并将永远不会出现在中央存储库上，并且您将获得额外的好处，即对更改进行版本控制并易于跟踪。第二种方法更符合 DVCS 的精神。
The short answer is "pull". From there, you have two options
You can either simply update, exactly as you would with svn, and your changes will remain local and non versionned, or you can commit and merge your changes with the head you pulled. If you don't push back, those merges will never appear on the central repo, and you will have the extra benefit of having your changes versionned and easy to track. The second method is much more in the spirit of DVCS.
@Axelle Ziegler 的答案中的两种方法是古老的“rebase vs .合并”决斗。
第一种方法需要更多解释。
首先，所有 DVCS 都鼓励频繁提交，这是相对 svn 等 CVCS 的一大优势，因此当您想要与上游同步时，您的本地更改（应该）可能已经提交。如果您不提交，
hg update默认情况下会尝试将您的更改合并到您要更新的修订版本中。有关详细信息，请参阅hg help update（注意：使用-C时要非常小心）。现在，如果您向上游拉动时确实有本地变更集，您将获得两个头（不是您，而是您的存储库）。然后你必须决定是合并还是变基。
hg 更喜欢并鼓励合并，因此 rebase 不是在核心中提供的，而是带有捆绑的扩展，您必须启用该扩展才能获取命令。
关于这个主题，有很多很好的问题和答案。如果您想切入正题，请阅读 此博客，看看创作者说了些什么。
当谈到 DVCS 时，几乎没有任何“简单”的问题:)
The two methods in @Axelle Ziegler's answer are the age-old "rebase vs. merge" duel.
The first method requires more explanation.
To start off, all DVCSs encourage frequent commit, which is one major advantage over CVCS like svn, so your local changes are (should) probably already committed when you want to sync with upstream. If you don't commit,
hg updateby default will try to merge your changes into the revision you're updating to. Seehg help updatefor details (note: be VERY careful with-C).Now if you do have local changesets when you pull upstream, you'll get two heads (no not you, but your repository). Then you must decide whether to merge or to rebase.
hg prefers and encourages merge, so rebase is provided not in core, but with a bundled extension that you have to enable to get the command.
There have been many good questions and answers here on the topic. If you like to cut to the chase, read the links in this blog to see what the Creators said.
There's hardly any "simple" question when it comes to DVCS :)