Mercurial工作流程，可以并行处理多个独立的任务

Question

这里有很多讨论已经解决了与这个问题有关的问题，但没有一个真正直接回答它。基本上，使用Mercurial，我希望能够在同一个项目中同时处理多个独立的任务。

例如，我同时负责错误X & Y.我在X上工作了一段时间，直到我遇到了一个需要搁置几天的时间。假设我需要来自不在办公室的其他人的意见。所以我想继续研究bug-Y。显然，一种选择是创建一个稳定版本库的新克隆。问题是需要一个新的工作目录，新的Eclipse项目，yada-yada ...我希望能够保留一个工作副本。

随着SVN我可以在存储库中为每个任务创建一个新的分支，只需切换我们之间的工作副本。使用ClearCase，我可以为每一个创建一个新的活动。在这两种情况下，我都可以在清洁的环境中独立完成每项任务。然后，当我完成一项任务时，我可以向中央仓库提交/推送该仓库。

我读过关于汞命名分支&的书签。我确信在那里有一个适合我们工作流程的解决方案，但我还没有看到它。有人可以解释我可以用来实现这一目标的步骤吗？是否有可能在我的本地存储库中创建两个头，我可以切换？然后更新/提交/推/拉这些头独立？在实践中，我甚至可能永远不会在本地合并它们，只要将它们在准备就绪时推送给我们的稳定回购。我是否完全错误地思考这个问题？我对Hg（以及DVCS的一般人员）非常陌生，并试图为其开发工作流程。

Answer 1

你所描述的过程是用水银来实现非常简单，而且有很多办法做到这一点。

例如，你可以使用匿名分支：

1. 将标签或书签上要用作发展都开始使用变更。
2. 开发你的第一个bug修正，做尽可能多的承诺，因为你需要
3. 当你要开始发展的另一条线，中庸之道更新之前保存的变更
4. 开发第二bug修正，并提交更改

您刚从已确定的变更集开始在您的工作副本中创建了两个匿名分支。

您绝对不限于匿名分支的数量或其出发点，您甚至可以在匿名分支上创建新的匿名分支。

在某些情况下，像TortoiseHG或在GraphLog extension工具确实能帮助你了解哪些是各个部门，什么是合并他们回来的最好办法的父母。

书签只是一种轻松跟踪各种变更集的方法，您可以将书签放在每个新的头上。根据您使用的Mercurial版本，书签将“跟随”您在其特定分支中进行的每个新提交或不提交。

你也可以使用命名分支实现相同的目的，但问题是你创建后不能轻易删除一个命名分支，名字仍然是它们的名字。

PS：这个工作流程，或某事在以下博客文章中描述非常相似：http://stevelosh.com/blog/2010/02/mercurial-workflows-branch-as-needed/

Answer 2

我通常只是为任何子项目或非平凡的错误修复创建命名分支。您可以通过'hg update'轻松地在分支之间来回切换。当我完成某些事情时，我只是将它合并回默认值。

下面是对在水银分支一些好的信息的文章： http://stevelosh.com/blog/2009/08/a-guide-to-branching-in-mercurial/

Answer 3

好了 - 所以我想我已经想通了这一点。我想我会使用命名分支。感谢大家的帮助。

这里有一些陷阱，我发现：

1. 合并的特性分支到“默认”当你准备推 - 你不能只是把你的分支到远程仓库
2. 当你推确保你选择只推'默认'分支 - 如果你不这样做，它会试图推动任何其他功能分支还没有推
3. Hg会抱怨说，你的推动是创建新的远程分支 - 没关系只要分支已经在本地合并了

如果有人看这个有进一步的意见和/或建议，我会很高兴听到他们。我对此解决方案还没有100％满意。

Answer 4

我写了一本关于using named branches for tasks的指南，你可能会觉得有用。你写在你的答案：

这里有一些陷阱，我发现：

• 合并的特性分支到“默认”当你准备推 - 你不能只是把你的分支远程仓库

当你想允许水银在远程存储库中创建一个新的命名分支你需要hg push --new-branch。这是因为分支机构是全球性的和长期的 - 所以你不应该用临时名称创建它们。

• 当你把确保您选择只推“默认”分支 - 如果你不这样做，它会尝试也推动尚未被排挤任何其他功能分支

你可以使用hg push --branch X来推动分支X（和任何祖先，当然）。

• 汞会抱怨你推正在创造新的远程分支 - 没关系，只要分支已经在本地
合并

事实上，在本地合并它没有任何与此有关消息 - 每当你引入一个新的分支时它就会出现，如果它被合并或不合并，它就不重要了。当你想在一个共享库中有多个头时，命名分支就是你使用的工具。通过命名分支机构，您可以避免在人们拉动和更新时出现混淆：即使可能存在X高度实验性和不稳定的代码分支，hg update default仍然会为您提供主要的开发线。

Answer 5

当处理多个任务/错误时，我更喜欢使用书签而不是命名分支。他们不会用分支信息混淆你的历史（但这可能是个人偏好）。

您通常只是在默认分支上工作。为了跟踪这个“发展的主线”，我们创建了一个名为“master”的书签（或者您想称之为）。在开始研究bug X之前，您需要创建一个书签“bugX”。

• 汞柱书签主
  • ...默认分支一如既往的工作...
• 汞柱书签bugX
  • ...上bugX
工作
• hg commit -m“bugX 1”
  • ...在bugX工作
• 汞柱提交-m “bugX 2”

然后，您必须在错误Ÿ工作，因为你必须例如等待别人的输入。为此，您首先返回到主书签（您离开“主线”的位置），为错误Y创建一个新书签并开始处理它。

• 汞柱更新主
• 汞柱书签bugY
  • ...上bugY
  工作
• 汞柱提交-m “bugY 1”

你也必须停止现在正在研究bug Y，并且你想继续在“主线”上工作。您首先从中央仓库获取最新的更改，然后开始在主分支上工作。功能完成后，您可以推送它。请务必只推主分支 “HG推-r大师”：

• 汞柱更新主
• 汞柱拉--rebase
  • ...在主工作
• 汞柱提交-m “新功能1”
  • ...工作在主
• 汞柱提交-m “新功能2”
• 汞推-r掌握

有时LASTER就可以完成错误X：

• HB更新bugX
  • ...上错误X工作
• 汞柱提交-m “bugX固定”

此bug修正现在必须进入主分支，并推到中央回购。你可以将它与“hg merge bugX”合并，或者更好 - 重新绑定它。当一切完成后，删除bugX书签：

• 汞柱更新bugX
• 汞柱变基-b bugX -d主
• 汞柱书签-f主
• 汞柱书签-d bugX
• 汞柱push -r master

需要使用“hg bookmark -f master”来让主书签现在指向bugX的最后一个变更集，这个变更集已经重新布置在主分支之上h（我认为这是通过mercurial 2.1自动完成的）。

现在可以使用bugY完成相同的过程，并且最终获得直线历史记录。

在团队中，您甚至可以考虑将主书签推送到中央存储库，以便在拉动（hg push -B master）后不会维护它。

这个工作流程也在this blog post或多或少有所描述。