假设一个项目是：
1产品Y多年来建造M模块L[1..3] 语言编写D开发什么时候项目包含太多或太少的实时分支？
我知道这是一个很难的问题，用数字来回答更难，但是我正在寻找量化的答案，如果可能的话，请制定一个公式。
背景
如果分支太少，代码永远不会准备好，开发人员不会进行大的更改，因为可能无法赶上下一个截止日期。同样，产品经理永远不会有足够的信心来命名某个版本。功能冻结通常会建立，新想法会延迟，开发速度会减慢。
如果分支太多，开发人员不确定他们的更改应该去哪里以及应该传播到哪里，哪个分支将合并到哪个主干。合并重构的代码非常困难。质量下降。此外，每个开发人员都必须在多个设置中测试他们的更改，浪费了大量的精力，开发速度变慢。
活分支数量的最佳范围是多少？
确定 RCS（svn 或 git）包含太多分支的经验法则是什么？
怎么样rule of 3：
许多 git 托管的项目只使用两个分支：master主干和vNext未来版本。
使用tags功能标记开发中的里程碑。
请允许您的开发人员在本地创建开发分支，并根据他们正在执行的任务将它们合并到这些远程分支。
要求开发人员向本地分支添加有意义的名称和描述。并相应地标记提交。
这个问题没有一个答案。它只能是“适合您的组织和工作流程的”。
恕我直言，一旦一个分支不再有用（例如，所有更改合并回主干。或者一个失败的实验/研究项目已被放弃或结束），它应该被删除。如果需要，您可以随时将其取回，这将有助于使事情变得更整洁。
根据您的编辑：如果有过时或“死”的分支，为什么它们仍然存在？根据定义，它们不再有用，所以只需删除它们。
如果您正在使用 git，那么即使它们已经死了，拥有多个分支也会很有用。您可以跟踪在哪个产品版本中引入了错误（按版本一分为二），您可以为许多小团队组织您的工作。您可以通过查看死树枝来了解为什么有些想法无法实现。
关键是一致性。尝试对分支进行分组以适应您的工作流程。例如，您可以拥有
stable- CI 从这个构建生产和/或登台staging- 从这个 CI 构建分期feature/*- 功能分支hotfix/*- 从 staging/stable 分支开始，用于修补程序experimental/*- 用于可能无法产生干净和可维护的代码或可能中途放弃的研发功能这里有一些基本提示：http: //nvie.com/posts/a-successful-git-branching-model/
此外，如果您希望您的团队快速开始使用良好的分支结构，请尝试使用 git flow：http: //jeffkreftmeijer.com/2010/why-arent-you-using-git-flow/
关于重构其他同事糟糕的代码。您可以使用一些refactor/*分支，这样您就可以通过在单独的分支上进行原子合并/变基来轻松查看损坏的内容。当然，测试是非常有用的，但是如果你不简单地git bisect告诉你是谁和什么时候引入了一个错误（如果你写一个测试来检查这个错误，那么你现在有一个有意义的测试可以添加到你的测试套件）。
底线是：不要害怕有很多分支，只要让它们井井有条。大多数情况下，合并并不像人们所说的那么复杂，您可以随时撤消它们（如果您不使用持续交付模型，则可以推迟到下一个版本）。
编辑：something/*我的意思是有多个具有共同something/前缀的分支，从而模仿目录结构。
EDIT2：在 SVN-likes 上情况有所不同，分支和合并并不便宜。谨慎行事；）
EDIT3：考虑为不同的模块使用不同的（子）存储库。它可能会简化开发。模块开发者只关心主应用的最新稳定版本，分支模型只面向一个模块。
EDIT4：问：“您是否可以考虑将一些数字或公式置于阈值之下，在该阈值之下可以接受凌乱的分支，而在该阈值之上可以更好地组织分支？”
当然！
公式（以我的拙见）很简单。
legacy/*或者简单dirty/*地想到）。将它们视为文件结构。您可以拥有许多不再需要的旧文件，但如果您以有组织的方式保存它们，您可以轻松地将存档与您的工作集分开。
看到你喜欢的数字，你可能想要这些分支的真实世界用例
让我举一个我一直在做的中小型 Symfony2 PHP 项目的例子。
如果您有一个项目持续 6-9 个月，由 5 名开发人员以敏捷（scrum）方式积极开发，每两周进行一次客户端演示，您可能希望拥有分支：
如您所见，这里也没有确切的数字。我已经完成了几个这种规模的项目，其中大多数都有大约 70-80 个分支（20-30 个没有用户故事分支）。如果它们以一种合乎逻辑、简洁的方式组织起来，那么代码存储库就很容易浏览。
使用 git 还可以考虑使用 rebase 而不是合并，这样您就不会出现合并气泡（查看这篇文章http://stevenharman.net/git-pull-with-automatic-rebase）。
确定 RCS（svn 或 git）包含太多分支的经验法则是什么？
没有任何。这样的通用规则不存在，并且（如果仍然可以定义任何本地规则）最后它依赖于团队和工作流。
使用“每个任务分支”，即使是中小型代码库，您也可能有很多短期分支（适用于任何规模的团队和使用的语言数量）
移自评论：
每个开发人员1-N 个未关闭的任务分支（N 取决于很多因素）每个开发人员 1-2 个活动+ 一些公共共享（稳定-不稳定-发布-...）
对于 Git 和 SVN，有不同的查看方式。但最重要的是拥有太多东西意味着什么，是出于性能原因还是组织原因。
所以git 性能：
在 git 中，分支只不过是对作为 git 存储库一部分的对象的引用。所以这个分支对象没有很大的开销。（有关更多信息，请参阅http://git-scm.com/book/en/Git-Branching-What-a-Branch-Is）如果您销毁分支，您的存储库中仍然拥有所有 git 历史记录，它只是得到它的问题。一般来说 - 分支没有额外的存储空间。如果您使用的是一次性分支，请删除，但您的提交仍然存在。git 的整体性能会因 repo 的大小而变慢，但不会创建分支以使其变得更大，提交是。您可以重新打包或删除对象以清理和加速您的 git 存储库。
所以SVN性能：
在 SVN 中，分支是工作树的副本，但是，这些副本不是重复数据。同样，它们是对现有树的引用——只要使用 svn-copy。（有关更多信息，请参阅http://svnbook.red-bean.com/en/1.1/ch04s02.html#svn-ch-4-sect-2.1）SVN可以很好地处理大文件和存储库，但同样， repo 不受分支机构的主要影响，相反，它们既高效又便宜。事实上，引用 svnbook 的话：“这里的重点是副本在时间和空间上都很便宜。你想多做分支就多做。”
SVN 和 git 的组织：
就像我上面说的，分支很便宜，所以它经常发生，一次性的分支应该被移除，但是历史分支很便宜。基本上，您应该有一种简单的方法来命名您的分支以进行约定：release_1、bugfix_200、temp_branch_for_fun - 任何使名称在按字母数字列出它们时自组织的东西。在 SVN 和 git 中使用标签也很好——人们倾向于对分支感觉更舒服，然而，在 git 中它们确实是相同的，在 SVN 中，它们对于时间点参考很有用。
多少分支太多 - 这是一个业务逻辑决策。我更喜欢为 Work In Progress 提供许多一次性分支，而只有历史分支用于发布。但这仅适用于迭代工作流程。最近我一直在将开发转向持续交付工作流程和分布式 git 分叉网络——然后我根本不在乎开发人员的 git fork 有多少分支——相反，我的源或主线存储库只有 1 个永久分支：master 和高优先级关键修补程序的一次性分支。
我上面提到的方法效果很好，因为现在每个开发人员都可以根据自己的喜好进行分支和遗忘，而不会打扰任何其他开发人员。同样，我的主人也没有杂乱的分支。（这也适用于迭代方法，并且只有发布的分支，没有临时或一次性的分支）。
大家都开心。
git 中的分支被认为是一次性的。如果您不需要它并且不会再次使用它，则将其丢弃。但是在我的情况下，我确实管理了很多分支，但只有 1% 的分支正在使用中。我已锁定其余部分，并确保我已将正确的标签应用于发布版本。
您可能需要定义所有相关分支是否同时处于活动状态。因为您可以有 100 个分支，但只有 1 个正在使用。但是，如果您要为 1 个项目拥有 100 个活动分支，那么是的，我会说这太多了，这表明管理不善。
希望这有帮助！
如果要存档分支，我认为通常的解决方案是将它们推送到存档仓库然后删除它们；如果你想要他们回来，你知道去哪里找。