Mercurial 中的最佳实践：分支与克隆以及部分合并？
...所以我已经习惯了 Mercurial 的简单操作（add、commit、diff）并发现了 .hgignore文件（耶！）并掌握了在分支之间创建和切换的窍门（branch、update -C）。
不过，我有两个主要问题：
如果我在分支“Branch1”中，并且我想从分支“Branch2”中提取一些但不是全部更改，我该怎么做？ 特别是如果所有更改都在一个子目录中。 （我想我可以克隆整个存储库，然后使用像 Beyond Compare 这样的目录合并工具来选择我的编辑。不过，似乎应该有一种方法可以隔离一个文件或一个目录中的更改。 )
使用
update -C在分支之间切换似乎很容易，我想知道为什么我要费心使用clone。 我只能想到几个原因（见下文）——还有其他一些我遗漏的原因吗？a. 如果我需要同时处理两个版本/分支（例如进行性能指标差异）
b. 用于备份（
将存储库克隆到物理上不同位置的网络驱动器）c. 像我上面提到的那样进行选择和选择合并。
...so I've gotten used to the simple stuff with Mercurial (add, commit, diff) and found out about the .hgignore file (yay!) and have gotten the hang of creating and switching between branches (branch, update -C).
I have two major questions though:
If I'm in branch "Branch1" and I want to pull in some but not all of the changes from branch "Branch2", how would I do that? Particularly if all the changes are in one subdirectory. (I guess I could just clone the whole repository, then use a directory-merge tool like Beyond Compare to pick&choose my edits. Seems like there ought to be a way to just isolate the changes in one file or one directory, though.)
Switching between branches with
update -Cseems so easy, I'm wondering why I would bother usingclone. I can only think of a few reasons (see below) -- are there some other reasons I'm missing?a. if I need to act on two versions/branches at once (e.g. do a performance-metric diff)
b. for a backup (
clonethe repository to a network drive in a physically different location)c. to do the pick&choose merge like I've mentioned above.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
我使用克隆的目的是：
前一种使用对我来说非常罕见 - 主要是当我尝试一个我可能想完全放弃的想法时。 如果我想合并，我会想要合并所有更改。 这种分支主要是为了跟踪不同开发者的分支，这样他们就不会互相干扰。 只是为了澄清最后一点：
对于功能分支或寿命较长的分支，我使用命名分支，这些分支可以更轻松地在存储库之间共享，而无需合并。 当您想要有选择地合并时，它也会“感觉”更好。
基本上我是这样看待它的：
这是我的看法，尽管这实际上是一个政策问题。
I use clone for:
The former use is pretty rare for me - mainly when I'm trying an idea I might want to totally abandon. If I want to merge, I'll want to merge ALL the changes. This sort of branching is mainly for tracking different developers' branches so they don't disturb each other. Just to clarify this last point:
For feature branches, or longer lived branches, I use named branches which are more comfortably shared between repositories without merging. It also "feels" better when you want to selectively merge.
Basically I look at it this way:
That's my take, though really it's a matter of policy.
对于问题 1，您需要更清楚地了解“更改”的含义。 您的意思是：
如果您指的是第 1 项，则应该查看 Transplant 扩展，特别是挑选一些变更集。
如果您指的是第 2 项，您将执行以下操作：
至于问题2，我自己从不使用存储库克隆来分支，所以我不知道。 我使用命名分支或匿名分支（有时带有书签）。
For question 1, you need to be a little clearer about what you mean by "changes". Which of these do you mean:
If you mean item 1, you should look into the Transplant extension, specifically the idea of cherrypicking a couple of changesets.
If you mean item 2, you would do the following:
hg revert -r <branch you want to merge> --include <files to update>to change the contents of those files to the way they are on the other branch.hg committo commit those changes to the branch as a new changeset.As for question 2, I never use repository clones for branching myself, so I don't know. I use named branches or anonymous branches (sometimes with bookmarks).
我有另一个选择供您研究：善变队列。
这个想法是，在当前工作目录之上有一堆补丁（没有提交，“真正的”补丁）。 然后，您可以添加或删除已应用的补丁，添加一个、删除它、添加另一个补丁等。一个补丁或其中的一个子集最终会成为一个新的“功能”，就像您可能想要对分支所做的那样。 之后，您可以照常应用补丁（因为这是一个更改）。 如果您与其他人一起工作，分支机构可能会更有用......？
I have another option for you to look into: mercurial queues.
The idea is, to have a stack of patches (no commits, "real" patches) ontop of your current working directory. Then, you can add or remove the applied patches, add one, remove it, add another other one, etc. One single patch or a subset of them ends up to be a new "feature" as you probably want to do with branches. After that, you can apply the patch as usual (since it is a change). Branches are probably more useful if you work with somebody else... ?