Mercurial 工作流程可并行处理多个单独的任务
这里有很多讨论解决了似乎与这个问题相关的问题，但没有任何一个真正直接回答它。基本上，使用 Mercurial，我希望能够同时处理同一项目中的多个独立任务。
例如，我同时负责处理 bug X 和 bug； Y. 我在 X 上工作了一段时间，直到我需要将其搁置几天。假设我需要不在办公室的其他人的意见。所以我想继续研究 bug-Y。显然，一种选择是创建稳定存储库的新克隆。问题是需要一个新的工作目录、新的 Eclipse 项目、yada-yada...我希望能够保留一个工作副本。
使用 SVN，我可以在存储库中为每个任务创建一个新分支，然后在它们之间切换我的工作副本。使用 ClearCase，我可以为每个活动创建一个新活动。在这两种情况下，我都可以在干净的环境中独立完成每项任务。然后，当我完成一项任务时，我可以将该任务提交/推送到中央存储库。
我读过有关 Hg 的名为 Branches & 的文章。书签。我确信那里有一个适合我们工作流程的解决方案，但我还没有看到它。有人可以解释我可以用来实现这一目标的步骤吗？是否可以在我的本地存储库中创建两个头，我可以在它们之间切换？然后独立更新/提交/推送/拉动这些头？在实践中，我什至可能永远不会在本地合并它们，只需在准备好后将它们推送到我们的稳定存储库即可。我只是以完全错误的方式思考这个问题吗？我对 Hg（以及一般的 DVCS）非常陌生，并尝试为其开发工作流程。
There are numerous discussions here that have addressed issues that seem related to this question, but nothing has really answered it directly. Basically, using Mercurial, I want to be able to work on multiple, independent tasks within the same project, at the same time.
For example, I'm simultaneously tasked with bugs X & Y. I work on X for a while until I hit a point where I need to put it on hold for a few days. Say I need input from someone else who is out of the office. So I want to move on to working on bug-Y. Clearly, one option is to just create a new clone of the stable repository. The problem is that requires a new working directory, new Eclipse project, yada-yada... I'd like to be able to keep one working copy.
With SVN I could create a new branch in the repository for each task and just switch my working copy between them. With ClearCase I could create a new activity for each one. In both cases, I could work on each task independently, in clean environment. Then when I'm done with a task, I can commit/push just that one to the central repo.
I've read about Hg named branches & bookmarks. I'm sure that somewhere in there there's a solution to fit our workflow, but I'm not seeing it yet. Can someone explain the steps I can use to achieve this? Is it possible to create two heads in my local repository that I can just switch between? And then update/commit/push/pull those heads independently? In practice I might never even merge them locally, just push each one to our stable repo when it's ready. Am I just thinking about this in entirely the wrong way? I'm very new to Hg (and DVCS's in general) and trying to develop a workflow for it.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
使用 Mercurial 实现您所描述的过程非常简单，并且有很多方法可以实现。
例如，您可以使用匿名分支：
您刚刚在工作副本中创建了两个匿名分支开始在决定的变更集中。
您绝对不限于匿名分支的数量或其起点，您甚至可以在匿名分支上创建新的匿名分支。
在某些情况下，TortoiseHG 或 GraphLog 扩展 等工具确实可以帮助您了解哪些是父级每个分支的详细信息以及将它们合并回来的最佳方法是什么。
书签只是轻松跟踪各种变更集的一种方式，您可以在每个新头上添加书签。根据您使用的 Mercurial 版本，书签将“跟随”您在其特定分支中所做的每个新提交或不“跟随”。
您也可以使用命名分支来达到相同的目的，但问题是您不能轻易删除创建的命名分支，名称仍然是他们的。
PS：以下博客文章中描述了此工作流程或非常类似的内容：http://stevelosh.com/blog/2010/02/mercurial-workflows-branch-as-needed/
The process you're describing is really simple to implement with Mercurial, and there's many way to do it.
For example, you can use anonymous branches :
You just created two anonymous branches in your working copy starting at the decided changeset.
You're absolutely not limited to the number of anonymous branches or their starting point, you can even create new anonymous branches on your anonymous branches.
In some cases, tools like TortoiseHG or the the GraphLog extension can really help you understanding which are the parents of each branches and what's the best way of merging them back.
Bookmarks are only a way to easily keep track of various changeset, you can put bookmark on each of your new heads. Depending on the version of Mercurial you're using, the bookmark will "follow" each new commit you make in its particular branch or not.
You can also use named branch to achieve the same purpose, but the problem is you can't easily delete a named branch after it's been created, the name will still be their.
PS: this workflow, or something very similar is described in the following blog post : http://stevelosh.com/blog/2010/02/mercurial-workflows-branch-as-needed/
我通常只是继续为任何子项目或重要的错误修复创建命名分支。您可以使用“hg update”轻松地在分支之间来回切换。当我完成某件事后，我只需将其合并回默认值。
这里有一篇文章，其中包含一些有关 Mercurial 中分支的好信息：
http://stevelosh.com/blog/2009/ 08/mercurial 分支指南/
I generally just go ahead and create named branches for any sub-project or non-trivial bug fix. You can switch back and forth between branches easily with 'hg update'. When I'm done with something, I just merge it back into default.
Here's an article with some good info on branching in Mercurial:
http://stevelosh.com/blog/2009/08/a-guide-to-branching-in-mercurial/
我写了一篇关于使用命名分支执行任务的指南，您可能会觉得有用。您在答案中写道：
您需要
hg push --new-branch 当您想要允许 Mercurial 在远程存储库中创建新的命名分支时。这是因为分支是全局性的并且是长期存在的——所以你不应该仅仅使用临时名称来创建它们。您可以使用 hg push --branch X< /code> 仅推送分支
X（当然还有任何祖先）。实际上，在本地合并它与此消息无关 - 每次你引入一个新分支时它都会出现，如果它是否合并。当您希望在共享存储库中拥有多个头时，命名分支实际上是您使用的工具。通过命名分支，您可以避免人们在拉取和更新时出现混乱：即使可能存在高度集成的
X分支，hg update default仍将为您提供开发的主线。实验性且不稳定的代码。I wrote a guide about using named branches for tasks that you might find useful. You write in your answer:
You need to
hg push --new-branchwhen you want to allow Mercurial to create a new named branch in the remote repository. This is because branches are global and long-lived — so you should not just create them with temporary names.You can use
hg push --branch Xto only push branchX(and any ancestors, of course).Actually, merging it locally has nothing to do with this message — it comes every time you introduce a new branch and it's not important if it's merged or not. Named branches are really the tool you use when you want to have multiple heads in a shared repository. By naming the branches, you avoid confusion when people pull and update:
hg update defaultwill still give you the main line of development even though there might be aXbranch with highly experimental and unstable code.当处理多个任务/错误时，我更喜欢使用书签而不是命名分支。它们不会用分支信息扰乱您的历史记录（但这可能是个人偏好）。
您通常只在默认分支上工作。为了跟踪这个“开发主线”，我们创建了一个名为“master”（或者您喜欢的名称）的书签。现在，在开始处理 bug X 之前，您需要创建一个书签“bugX”。
然后您必须处理 bug Y，因为您必须等待其他人的输入。为此，您首先返回主书签（您离开“主线”的位置），为错误 Y 创建一个新书签并开始处理它。
您现在还必须停止处理 bug Y，并且您想继续在“主线”上工作。您首先从中央存储库获取最新更改，然后开始在主分支上工作。当该功能完成后，您可以推送它。确保仅使用“hg push -r master”推送 master 分支：
上工作有时最后你可以完成 bug X:
现在必须将此 bug 修复引入 master 分支并推送到中央存储库。你可以将它与“hg merge bugX”合并，甚至更好 - rebase it。一切完成后，删除bugX书签：
"hg bookmark -f master" 需要让master书签现在指向 bugX 的最后一个变更集，该变更集已在 master 分支之上重新构建（我认为这是使用 Mercurial 2.1 自动完成的）。
现在可以使用 bugY 完成相同的过程，最终您会得到一条直线历史记录。
在团队中，您甚至可以考虑将主书签推送到中央存储库，这样在拉取后就不必维护它（hg push -B master）。
这篇博文也或多或少地描述了此工作流程。
When working on multiple tasks/bugs, I prefer using bookmarks over named branches. They do not clutter your history with branching info (but this may be a personal preference).
You normally just work on the default branch. To keep track of this "main line of development", we create a bookmark named "master" (or however you'd like to call it). Now before you start working on bug X, you create a bookmark "bugX".
You then must work on bug Y, because you have to e.g. wait for input of someone else. To do this, you first go back to the master bookmark (where you left the "main line"), create a new bookmark for the bug Y and start working on it.
You also have to stop working on bug Y now and you want to continue your work on the "main line". You first grab the newest changes from the central repo and then start working on the master branch. When the feature is finished, you can push it. Be sure to only push the master branch with "hg push -r master":
Sometime laster you can finish bug X:
This bugfix must now be brought into the master branch and be pushed to the central repo. You could merge it with "hg merge bugX" or even better - rebase it. When everything is done, delete the bugX bookmark:
"hg bookmark -f master" is needed to let the master bookmark now point to the last changeset of bugX that has been rebased on top of the master branch (I think this is done automatically with mercurial 2.1).
The same procedure can now be done with bugY and you end up with a straight line history.
In a team, you could even consider pushing the master bookmark to the central repository so that it has not to be maintained after pulling (hg push -B master).
This workflow also is described more or less in this blog post.
好吧 - 所以我想我已经弄清楚了。我想我会使用命名分支。感谢大家的帮助。
以下是我发现的一些问题：
如果有人看这个有进一步的意见和/或建议我会很高兴听到他们的声音。我对这个解决方案还不是 100% 满意。
Ok - so I think I've figured this out. I think I'll be using named branches. Thanks for everyone's help.
Here are a few gotchas I found:
If anyone looking at this has further comments and/or suggestions I'll be glad to hear them. I'm not 100% satisfied with this solution yet.