我使用mercurial进行源代码控制。我想要一个主开发分支，然后有时间点与“v1.0”“v1.01”和“v2.0”对齐，这样我可以随时下拉说“v2.0 “并粉碎一些错误。我听说有些人说我需要标签，有人说我需要书签，有些人说我需要命名分支，还有人说我只需要维护多个克隆的存储库。
从我的角度来看，多个克隆的回购似乎是一个糟糕的选择，因为我喜欢DVCS的一件事是，一旦你克隆了“回购”，你就拥有了所有过去的历史，如果你的中央服务器可以完全恢复某些笔记本电脑烧毁了。如果您的回购分散在各地，我觉得您失去了这个好处，除非您希望人们克隆5个回购并在本地维护它们的计算机。这让我很担心，因为大多数人都说这是一个很好的方法，但从逻辑上讲，这对我来说没有意义。 （我知道这不是一种正确的备份方式，但是如果没有回到服务器就无法完全访问部分仓库对我来说似乎很奇怪）
所以对我而言，将所有内容保持在一起的方式必须是标签，命名分支或书签。但是，我似乎无法区分这些。人们倾向于将书签解释为“有点像标签，有一些警告”，并且将分支命名为某种移动标签，这可能更适合使用克隆。
我真的很喜欢git样式分支（单个repo，多个分支），但是，我不想诉诸奇怪的插件或黑客让它看起来像git。我想了解正确的善变方式。
Bonus：“小规模”分支如何适应混合，即你想在自己的分支中处理一个小特征？
答案 0 :(得分：2)
命名分支 - 在每次提交时，都会有一个提交所针对的分支的字段。除此之外，具有命名分支的repo和具有多个head的repo之间没有区别。合并命名分支时，它就像常规合并一样，分支名称取自当前活动的分支。这很可能是你想要的长期v1.x分支。
书签 - 浮动标签很像您的存储库中的提示。仅限本地，除非您进行某种边带同步。适用于功能分支或需要跟踪正在发生但不需要与他人共享的内容。
标签 - 如果您需要确切知道在v1.0上发布的内容，那么命名提交就会很好
我会使用名称分支来开发1.x分支2.x分支等。然后使用标记标记实际发布的版本1.0，1.1将在1.x树上完成然后1.1版本将成为其中的标签。我不会将书签作为流程的一部分，因为你必须手动同步它们。（注意，较新版本的mercurial书签可以远程同步，但它仍然需要用户干预。）
答案 1 :(得分：2)
我从来没有理解将克隆回购作为匿名分支的想法。
hg branch feature-name是我喜欢滚动的方式。
答案 2 :(得分：0)
像Mercurial或Git这样的DVCS可以轻松克隆回购。这并不意味着您将其用于发布管理工作流程。
每个人都有完整的mercurial repo只是DVCS的副作用。这意味着当主存储库丢失时会出现冗余。
您可以通过一种方式使用DVCS，您可以拥有一个主存储库，您可以在其中推送更改并从中提取更改，就像客户端 - 服务器VCS（颠覆）一样，具有可以脱机工作的附加优势。
对于您的发布管理工作流程，您仍应查看
关于每个主题的SO都有足够的讨论。
以下提供了有关使用克隆，书签和命名分支进行分支的良好简要信息
答案 3 :(得分：0)
我使用mercurial进行源代码控制。我想要一个主开发分支，然后有时间点与“v1.0”“v1.01”和“v2.0”对齐，这样我可以随时下拉说“v2.0 “并粉碎一些错误。
我建议您标记每个发布版本。
如果您需要针对先前版本发布错误修复，您将首先创建命名分支或基于版本标记克隆新存储库。一旦你处理了这个bug，就可以将bug修复程序合并到你的主要开发分支中。
无论您使用命名分支还是克隆都没关系，因为结果是相同的：修复了错误，修复程序被释放到以前的版本，修复程序被合并到主开发分支中。阅读other answers，尝试两种方法，然后使用您喜欢的方法。就个人而言，我为这些长期存在的发布分支使用命名分支，以便每个应用程序发行版的所有历史记录都存储在一个存储库中。
所以......按需“标记每个版本和分支。”
答案 4 :(得分：0)
您需要标记来标记v1.0，v1.01和v2.0等版本。对于分支开发（错误修正，功能分支等），您可以使用书签 - 它们现在得到很好的支持协作使用（见http://mercurial.aragost.com/kick-start/en/bookmarks/#sharing-bookmarks）。如果您需要拥有长期分支（即在可预见的将来它们将在回购中），请使用命名分支。他们将是一个很好的选择，例如有v1，v2，......发展的分支。
您可以单独使用书签或仅为两个短命和长期分支命名分支，但是当您可以时，更喜欢书签已成为标准做法。< / p>
另请参阅mercurial: mix named branches and bookmarks，了解书签和命名分支的不同之处的快速图解答案。