活分支数量的最佳范围是多少？ [关闭]

假设一个项目是：

• 1 product
• 建立在Y years
• 包括M modules
• 写在L[1..3] 语言
• 总共开发了D开发商

项目在什么时候包含太多或太少的实时分支？

我知道这是一个很难的问题，用数字来回答就更难了，但是我正在寻找量化的答案，如果可能的话，请制定一个公式。

背景

如果分支太少，代码永远不会准备好，开发人员不会进行大的更改，因为可能无法满足下一个截止日期。同样，产品经理也永远没有足够的信心来命名某个版本。功能经常被冻结，新想法被延迟，开发速度减慢。

如果分支太多，开发人员不确定他们的更改应该去哪里以及应该传播到哪里，哪个分支将合并到哪个主干。合并重构的代码非常困难，质量下降。此外，每个开发人员都必须在多个设置中测试他们的更改，浪费了大量精力，开发速度减慢。

活分支数量的最佳范围是多少？

确定 RCS（svn 或 git）包含太多分支的经验法则是什么？

怎么样rule of 3:

• 稳定代码的一个分支——主干；
• 不稳定的一个分支 - 即将发布的开发；
• 还有一个用于维护 - 上一版本的错误修复；

许多 git 托管的项目仅使用两个分支：master用于主干线和vNext以供将来发布。

Use tags用于标记开发中里程碑的功能。

请允许您的开发人员在本地创建开发分支，并根据他们正在执行的任务将它们合并到这些远程分支。

要求开发人员为当地分支机构添加有意义的名称和描述。并相应地标记提交。