假设一个项目是：
1产品Y年M个模块L [1..3]种语言撰写D个开发者总数项目在什么时候包含太多或太少的实时分支？
我知道这是一个很难回答的问题，在数字上更难回答，但我正在寻找量化的答案，如果可能的话，请制定一个公式。
背景
如果分支太少，代码永远不会准备好，开发人员不会进行大的更改，因为可能无法满足下一个截止日期。同样，产品经理也没有足够的信心为某个版本命名。通常会建立功能冻结，新想法会延迟，开发速度会慢下来。
如果分支太多，开发人员不确定他们的更改应该去哪里以及应该在哪里传播，哪个分支将合并到哪个主干。合并重构代码非常困难，质量下降。此外，每个开发人员必须在几个设置中测试他们的更改，浪费了相当大的努力，开发速度变慢。
活枝数的最佳范围是什么？
答案 0 :(得分：10)
这个问题没有一个答案。它只能是“适用于您的组织和工作流程的内容。”
恕我直言，一旦一个分支已经失去其实用性（例如，所有变化合并回主干，或者已经放弃或结束的失败的实验/研究项目），它应该被删除。如果需要，你可以随时取回它，这将有助于使事情变得更加整洁。根据您的编辑：如果有分支已过时或“死”，为什么它们仍在？根据定义，它们不再有用，所以只需删除它们即可。
答案 1 :(得分：10)
确定RCS（svn或git）包含太多分支的经验法则是什么？
rule of 3：
许多git托管项目只使用两个分支：master用于主干，vNext用于将来版本。
使用tags功能标记开发中的里程碑。
请允许您的开发人员在本地创建开发分支，并根据他们正在执行的任务将它们合并到这些远程分支。
要求开发人员向本地分支机构添加有意义的名称和描述。并相应地标记提交。
答案 2 :(得分：8)
如果你使用git有多个分支可能是有用的，即使它们已经死了。您可以跟踪引入错误的产品版本（按版本分类），您可以为许多小团队组织工作。你可以看到为什么有些想法只是通过查看死枝来解决问题。
关键是一致性。尝试将分支分组以适合您的工作流程。 例如，您可以
stable - CI从此构建生产和/或暂存staging - CI构建暂存feature/* - 功能分支hotfix/* - 从staging / stable分支开始，用于修补程序experimental/* - 用于R＆amp; D功能，可能不会产生干净且可维护的代码，或者可能会被中途放弃这里有一些基本提示： http://nvie.com/posts/a-successful-git-branching-model/
此外，如果您希望您的团队快速开始使用良好的分支结构，请尝试使用git flow：http://jeffkreeftmeijer.com/2010/why-arent-you-using-git-flow/
关于重构其他同事的坏代码。您可以使用一些refactor/*分支，这样您就可以轻松地看到在单独的分支上具有合并/重组原子的原因。当然，测试非常有用，但是如果你没有，一个简单的git bisect会告诉你谁和什么时候引入了一个bug（如果你编写一个测试来检查这个错误，哪个bisect会使用你现在有一个有意义的测试添加到您的测试套件中。）
底线是：不要害怕拥有多个分支，只要让它们井然有序。合并大部分时间并不像人们所说的那么复杂，你可以随时撤消它们（如果不使用连续交付模式，则推迟到下一个版本）。
编辑：通过something/*我的意思是拥有多个带有公共something/前缀的分支，从而模仿目录结构。
EDIT2：SVN喜欢的东西不同，分支和合并并不便宜。谨慎行事;）
EDIT3：考虑为不同的模块使用不同的（子）存储库。它可能会简化开发。模块开发人员只关注主应用程序的最新稳定版本，而分支模型仅面向一个模块。
EDIT4：问：“您是否可以考虑将一些数字或公式置于阈值以下，以便可以接受凌乱的分支，哪些分支可以更好地组织？”
当然！
公式（以我的拙见）很简单。
legacy/*或普通dirty/*会浮现在脑海中。将它们视为文件结构。您可以不再需要许多旧文件，但如果以有组织的方式保留它们，则可以轻松地将存档与工作集分开。
看到你喜欢的数字你可能想要这些分支的真实世界用例
让我举一个我一直在研究的中小型Symfony2 PHP项目的例子。
如果您有一个项目持续6-9个月，由5位开发人员以敏捷（scrum）方式积极开发，每两周进行一次客户端演示，您可能希望拥有分支机构：
正如您所看到的，这里也没有确切的数字。我做了几个这样大小的项目，其中大多数都有大约70-80个分支（20-30个没有用户故事分支）。如果它们以逻辑清晰的方式组织，则代码存储库易于浏览。
使用git考虑重新绑定而不是合并，因此您不会获得合并泡沫（请查看本文http://stevenharman.net/git-pull-with-automatic-rebase）。
答案 3 :(得分：3)
确定RCS（svn或git）包含太多分支的经验法则是什么？
无。这种常见规则不存在（如果任何本地仍然可以定义），最后它依赖于团队和工作流程。
使用“每个任务分支”，即使是小型和中型代码库，也可能有很多短期分支（适用于任何规模的团队和使用中的语言数量）
从评论中移出：
1-N 未关闭任务分支每个开发人员（N取决于很多因素）1-2 每个开发人员 +一些常见的共享（stable-unstable-released -...）
答案 4 :(得分：3)
对于Git和SVN，有不同的方法来查看它。但最重要的是，由于性能原因或组织原因，有太多东西意味着什么。
所以 git performance ：
在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分叉网络 - 然后我根本不关心dev的git fork有多少分支 - 而我的源或Mainline存储库只有1个永久分支：master和高优先级关键修补程序的一次性分支。
我上面提到的方法效果很好，因为现在每个开发人员都可以尽可能地分支和忘记，而不会让任何其他开发人员烦恼。同样，我的主人不受分支混乱的影响。 （这也适用于迭代方法，并且只有发布的分支，没有临时或一次性分支。）
每个人都很开心。
答案 5 :(得分：0)
git中的分支被认为是一次性的。如果您不需要它并且不再使用它，请将其丢弃。但是在我的情况下，我确实管理了很多分支，但只有1％的分支正在使用中。我锁定了其余部分并确保我已将适当的标签应用于发行版本。
您可能需要定义所有相关分支是否一次处于活动状态。因为你可以有100个分支，但只有1个正在使用中。但是，如果你有1个项目的100个活跃分支，那么我会说太多了，它只是表明管理不善。
希望这有帮助！
答案 6 :(得分：0)
如果你想归档分支机构，我认为通常的解决方案是将它们推送到归档仓库，然后删除它们;如果你想要他们回来，你知道在哪里看。