<分区>
假设一个项目是:
1 产品- build 了
Y 年
- 包含
M个模块
- 用
L [1..3] 种语言编写
- 由
D 开发人员开发
项目在什么时候包含太多或太少的事件分支？
我知道这是一个很难的问题，用数字回答更难，但是我正在寻找量化的答案，如果可能的话，请做一个公式。
背景
如果分支太少，代码永远不会准备好，开发人员不会进行大的更改，因为可能无法满足下一个截止日期。同样，产品经理永远不会有足够的信心将某个东西命名为发布。经常会出现功能卡住、新想法被推迟、开发速度减慢。
如果分支太多，开发人员不确定他们的更改应该去哪里，应该传播到哪里，哪个分支将 merge 到哪个主干。 merge 重构代码非常困难。质量下降。此外，每个开发人员都必须在多个设置中测试他们的更改，浪费了大量的精力，开发速度变慢。
活跃分支数量的最佳范围是多少？
What is the rule of thumb to determine that RCS (svn or git) contains too many branches?
3 规则 怎么样:
- 稳定代码的一个分支——主干；
- 不稳定的一个分支——即将发布的开发；
- 还有一个用于维护——以前版本的错误修复；
许多 git 托管的项目只使用两个分支:master 用于主干，vNext 用于 future 发布。
使用 tags 功能来标记开发中的里程碑。
请允许您的开发人员在本地创建开发分支，并根据他们正在执行的任务将它们 merge 到这些远程分支。
要求开发人员为本地分支添加有意义的名称和描述。标签相应地提交。