Let's say a project is:
1
productY
yearsM
modulesL
[1..3] languagesD
developersAt 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
:
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.