在使用Mercurial或类似DVCS工具版本的大型Libre Source软件项目中，以下哪项被认为更为传统：
default分支中保留最新的“稳定”版本软件。在default中标记每个版本，以便您知道哪个版本已打包为下载。测试后立即将补丁合并到default。保持命名分支中的新功能等在下一版本中合并到default。 default来保留仅供开发人员或非常愚蠢的人使用的前沿代码。或者......是否有一些被广泛接受的更好的工作流模式？
答案 0 :(得分：4)
Mercurial对您应该使用default分支的内容有相当强烈的意见。它记录在Standard Branching wiki page中。摘要是：
您不应将default以外的名称用于主要开发分支。
原因是default是新克隆检出的分支。如果您尝试为“主”分支使用其他名称，则用户在克隆并在错误的位置提交内容时会获得或多或少的随机分支，这通常是不可取的。
即使有大量文档说“在添加新功能之前进行分支”（参见下一点），人们在向您发送补丁时也会忘记这一点。然后，他们通过移动变更集来解决问题。
所以总是把最前沿的代码放在default分支中，并使用其他分支来保存稳定版本。
不要将分支名称视为一次性
分支名称是每个提交的永久部分，并允许识别每个提交引入的分支。因此，您需要考虑一下您的分支名称，以免污染分支命名空间。
此外，如果您尝试使用每个错误修复的分支，您最终可能会遇到性能问题。 Mercurial及其周围的工具旨在与数百个分支机构配合使用。 Mercurial本身仍然可以很好地运行一万个分支，但是一些命令可能会显示出明显的开销，只有在工作流程稳定后才会看到。
我们在Mercurial内部有缓存，因此问题主要是UI问题：托管站点和日志查看器可能会运行hg branches以将所有10,000个分支加载到单个下拉菜单中。对于想要从巨大的菜单中选择一个分支的穷人来说，这真的很慢而且毫无用处。
如果分支已关闭，则它们不会显示在hg branches中，因此应尽量减少问题。但是，工具可能也希望显示封闭的分支 - 这一切都取决于工具。
对不起，这有点模糊。重点是Mercurial的构建是为了扩展 changesets 的数量，而不是命名分支的数量。我们用前面提到的缓存来解决命名分支的最大性能问题，所以今天我不太关心有多个分支，特别是如果开放分支的数量保持很小（比如100）。 / p>
答案 1 :(得分：3)
如果在Mercurial中使用默认值并在Git中使用默认实际工作，最前沿，并使用标签和分支来释放，我已经养成了习惯。 hgsubversion和Git-Svn似乎采取了这种策略。
答案 2 :(得分：2)
通常没有“大多数常规”这样的事情 - 每个工作流程都是本地惯例和开发政策的问题
我经常看到提到的政策和中间变化 - 也是。 如果强大的测试|释放策略和密集使用的分支（“每个任务的分支”）“默认”分支通常仅作为仅合并分支（在QA测试之前从功能分支合并）并且意味着“代码，它使用完成的功能，不会抛出错误，但具有未经测试的功能“。 次要版本形成命名分支，这种分支中的每个版本都是标记。在完成“默认”和活动版本分支 但是这个工作流程只是又一个例子，并不比其他工作流程更好，适合于建立责任分离的中型团队，在“混乱的无政府状态”发展中效果不佳
答案 3 :(得分：1)
它的数量不多。如果我们谈论的只是DEV＆amp; STABLE分支，默认主要只是一个命名约定。我倾向于将DEV作为默认设置，因为大多数工作都在dev分支上进行，如果这是默认分支，那么它就更少了。
我个人更喜欢每个版本的命名分支。然后，在使用hg merge之后，错误修正可以在这些分支上进行，并且相对容易地向前移植到所有版本。如果您尝试使用DEV和STABLE执行相同操作，则只能拥有一个维护版本（最后一个），或者您的稳定分支开始增长分支，并且每个版本最终会得到一个（可能不那么有组织）版本的分支结构