What is the optimal range for number of live branches?

Let's say a project is:

• 1 product
• built over Y years
• comprising M modules
• written in L [1..3] languages
• developed by total of D developers

At what point does a project contain too many or too few live branches?

I know it is a hard question, it is even harder to answer numerically, I am however looking for quantified answers, if at all possible, please make a formula.

Background

If there are too few branches, code is never ready, developers don't make large changes because it may be impossible to meet next deadline. Likewise product managers never feel confident enough to name something a release. Feature freeze is often established, new ideas are delayed, development slows down.

If there are too many branches, developers are unsure where their changes should go and where they ought to be propagated, which branch will be merged to which trunk. Merging refactored code is very hard., quality goes down. Moreover, each developer has to test their changes in several setups, considerable effort is wasted, development slows down.

What is the optimal range for number of live branches?

What is the rule of thumb to determine that RCS (svn or git) contains too many branches?

How about rule of 3:

• One branch for stable code — main trunk;
• One branch for unstable — upcoming release development;
• And one more for maintenance — previous release's bug-fixes;

Many git-hosted projects use only two branches: master for main trunk and vNext for future release.

Use tags feature for labeling milestones in your development.

Please allow your developers to create development branches locally and merge them to these remote branches depending on the task they are performing.

Ask developers to add meaningful names and descriptions to the local branches. And label commits accordingly.