我会更具体地提出一个问题，如果我需要的话，或者如果你认为它适合的话，将它变成一个社区维基，但我的问题是：
我的开发团队最近开始使用Mercurial（从颠覆中移除），到目前为止我们都喜欢它。我想知道存储库架构是否存在“最佳实践”资源。我感兴趣的是，在处理功能和新版本时，保留repo的稳定副本（用于运送/紧急错误修复）的最佳方法是什么。我已经阅读了很多关于命名分支和克隆存储库的内容，我希望你们中的一些人可以对你们团队的工作有所了解。
在功能测试完成并准备好下一个版本后，更容易合并？我提到的两种方法有任何严重的缺点吗？那里有其他的回购管理策略吗？
我们正在接近部署我们的2.0.0版本，并且我希望一旦它以hg的新工作方式出现就重新开始。
让我重新讲述一些我仍在努力的基础知识 - 假设我明天完成2.0.0 ...我想开始研究2.1.0，我该怎么做做？克隆我的回购，将其命名为“working / projects / widgets2.1”并继续滚动，让我的“workin / projects / widgets2.0”准备好用于修复错误的情况吗？
此外，如果客户打电话并说有一个错误并且小部件机器正在摇晃并且烟雾开始滚滚，我是否会弹出打开小部件2.0，修复错误，部署到服务器，然后提交/推送？然后我回到widgets2.1并拉/合并那个bug修复？
答案 0 :(得分：7)
我希望我之前听过的建议是“尽早修复错误”，我并不是说你编码之后。我的意思是，如果您要修复两年前变更集400中引入的错误，您应该这样做：
hg update 400
vi .... # fix bug
hg commit
Mercurial会说“新头创建”，一开始看起来很惊人，但你所做的是创建一个变更集（实际上是一个匿名分支），可以hg pull进入任何有bug的分支
在我弄清楚这一点之前，我们会在发布分支，开发分支或其他一些活动的开发线上修复错误，然后我们要将该修复移动到其他分支，并且不能做得好。原因是当你拉（分支作为克隆）或合并（命名或匿名分支）时，公司要求如果你正在拉/合并变更集X然后你拉动/合并变更集X的所有祖先 - 但是你不一定想要所有这些祖先（可能是新的实验性功能），你只是想要修复错误。
在没有祖先的情况下进行更改需要通过导入/导出或移植或其他一些带外机制来“挑选”另一种形式。
但是，如果您使用bugfix更改集，使得它们的唯一祖先就是首次创建错误的变更集，那么您可以随时将“修复”修复到任何有错误的分支中，而不会带来任何其他内容
只是将它更多地恢复到原始查询，如果您将克隆用作分支（我的偏好）或命名分支，我上面建议的内容同样适用。
答案 1 :(得分：7)
据我所知，您所询问的是如何处理Mercurial中不同的开发分支。在您的示例中，您希望能够轻松地将修订版发布到发行版，而无需处理自上一版本以来开发分支中发生的所有内容。
在Mercurial中处理分支的方法有很多种。您可以使用单独的存储库，命名分支和Bookmarks扩展等。您如何选择在Mercurial中处理分支与您拥有的工作流类型有关，但有许多可能的组合。
考虑到这一点，我将为分支之间的工作流程提供一些一般性建议，无论它们如何在Mercurial中表示（作为单独的存储库，命名分支等）。如果您想详细了解要选择的分支模型，建议您阅读Steve Losh's guide to branching in Mercurial上的choosing a branching model in Mercurial和我的博客帖子。
首先，即使根本没有分支，您仍然可以始终返回到代码的早期版本，例如2.0发布，修复那里的bug。这样可以轻松标记和发布新版本（例如2.0.1），唯一的变化是修复错误。
您只需更新，修复和提交即可完成此操作：
$ hg update 2.0
hack hack hack
$ hg commit -m "Fix nasty bug"
$ hg tag 2.0.1
以上假设您已经标记了2.0修订版，因此很容易获得它，否则您将不得不提供哈希或修订版ID。
这将为您提供两个头，您可以与hg merge合并，将修复程序恢复到开发版本。
如果您有一个单独的2.0版本存储库，则在那里进行修复，然后将其拉入开发存储库，然后进行合并。基本原则是Ry4an概述的那个，你在没有做出一些你不想要的其他改变的地方做出改变。
以下是一个例子：
在我工作的地方，我们有许多代表不同分支的存储库。大多数开发都发生在“dev”分支中。当发布接近时，我们将该存储库克隆到名为“release-2.4”的新存储库中。在这个分支/ repo中，我们测试并修复即将发布的bug。更多的实验性开发在下一个版本发布之前就不会在“dev”中并行发生。
当测试版本准备好发布时，我们将所有内容从“release-2.4”拉到“prod”，其中只包含已发布的代码版本。我们用版本号标记它并将其发布到世界各地。然后我们可以删除“release-2.4”分支，并将所有内容从“prod”拉到“dev”。这可能需要合并，但随后我们将在发布过程中所做的所有更改都放回到“dev”中，并且可以继续处理下一个版本。
如果我们想在更大的计划版本之外修复错误，我们可以通过几种方式来解决。如果修复很小（几个提交）或者不涉及很多开发人员，我们可以直接提交“prod”，标记发布并发布它。之后我们从“prod”拉到“dev”，以确保在下一个版本中也有修复。
如果错误修复版本更大并且需要更多时间，我们可以改为关闭“prod”的新分支，在那里释放所有我们的工作，然后将更改拉到“prod”。当它被释放到“prod”时，我们可以从“prod”“拉”到“dev”以获得那里的变化。然后可以删除特殊版本分支。
答案 2 :(得分：0)
这是一个很好的“结构”教程：
我在熟悉Subversion之后也开始使用Mercurial，我对开关非常满意 - hg肯定为我解决了一些问题。我基本上不打扰任何“命名的分支”，只是依靠头来完成我的工作。我确保充分利用日志来确定在需要返回旧版本时我需要去哪里。当然，标签也非常好，教程涵盖了这一点。
答案 3 :(得分：0)
我工作的公司很乐意迁移到Mercurial并考虑为正在开发的每个功能支持“功能分支”。功能分支是一个命名分支，它包含一些新的开发或现有功能的更新 - 基本上，无论您想要什么。
功能分支仅存在于用户的repo克隆中，直到它们准备好集成到开发主线中，此时它们才会合并回活动开发分支。如果某人处于构建管理员角色，则可以将功能分支推送到未合并的共享仓库，管理员可以根据需要合并它们。如果不这样做，开发人员可以将它们合并到克隆的repos中，然后推送已经合并的分支。 （旁注：Hg仍然会在共享仓库中显示合并的功能分支）
一旦共享仓库更新到稳定点，就可以对其进行标记和发布。错误修正可以应用于标记版本，如果需要延长或并行开发，可以使用标记版本作为父版本创建第二个活动开发分支。 Ry4an的错误修正方法也可以在这里应用。
可以使用功能克隆而不是功能分支复制整个工作流程，但它会改变一些开发动态。如果你有能力让每个人尝试发布，那么这应该有助于你和你的团队做出决定。
编辑以解决新添加的特定问题
假设我明天完成2.0.0 ......我 想要开始2.1.0的工作，我该怎么做 办？
在此方案中，您将在2.0.0完成后创建一个标记，然后在默认分支上继续使用2.1.0。从此点开始，对默认分支和任何新功能分支的后续提交将支持2.1.0。
此外，如果客户打电话和 说有一个bug和小部件 机器在颤抖，烟雾是 开始滚滚，我是否开放 widgets2.0，修复bug，部署到 服务器，然后提交/推送？
2.0.0的错误修正将通过更新到2.0.0变更集（即：标记）然后创建新的命名分支（可能称为 version2.0.0 ）来完成。此分支永远不会完全合并到默认分支中，该分支现在已转移到2.1.0开发，并且此分支可能会无限期地保持打开状态。它将包含任何基于2.0.0的错误修正。
一旦你做了2.0.0错误修正，有几种方法可以将特定的chagneset从2.0.0移动到默认（2.1.0）分支。您可以创建特定变更集的补丁并将其应用于默认分支，也可以执行从 version2.0.0 到默认的合并如果有意义的话。