What is the optimal range for number of live branches? [closed]

Question

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?

Answer 1

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.

Answer 2

If you're using git having multiple branches can be useful, even if they're dead. You can track in which product version the bug was introduced (bisect by versions), you can organize your work for many small teams. You can see why some ideas didn't work out just by looking at dead branches.

The key is consistency. Try to group your branches to fit your workflow. You can for example have

• stable - CI builds production and/or staging from this one
• staging - CI build staging from this one
• feature/* - branches for features
• hotfix/* - started from staging/stable branch, used for hotfixes
• experimental/* - used for R&D functionality that might not result in clean and maintainable code or may be abandoned halfway through

Some basic tips here: http://nvie.com/posts/a-successful-git-branching-model/

Also, if you want your team to quickly start using a good branch structure try git flow: http://jeffkreeftmeijer.com/2010/why-arent-you-using-git-flow/

About refactoring other co-workers bad code. You can use some refactor/* branches so you can easily see what broken by having merges/rebases atomic on a separate branch. Of course having tests is EXTREMELY useful, but if you don't a simple git bisect will show you who and when introduced a bug (and if you write a test to check for this bug which bisect would use you now have a meaningful test to add to your test suite).

Bottom line is: don't be afraid of having many branches, just keep them organised. Merges most of the time aren't that complex as people say they are and you can always undo them (or postpone till the next release if you aren't using continous delivery model).

EDIT: By something/* I mean is having multiple branches with a common something/ prefix, thus mimicking a directory structure.

EDIT2: Things are different on SVN-likes, where branching and merging isn't that cheap. Proceed with caution ;)

EDIT3: Consider using different (sub)repositories for different modules. It might simplify the development. Module developers are only concerned by the latest stable version of the main application and branch model is only oriented towards one module.

EDIT4: Q: "can you perhaps consider to put some numbers or formulae at the threshold below which messy branching is acceptable and above which branches better be organised?"

Sure!

Formula (in my humble opinion) is simple.

• have as many 'dirty' branches locally as you want (just don't push them to other people or shared repositories)
• try not to push dirty branches unless they represent some value for other developers. If you have them already in your shared repository keep them and rename them (legacy/* or plain dirty/* comes to mind).

Think of them as a file structure. You can have many legacy files no longer needed but if you keep them in an organised manner you can easily separate the archive from your working set.

Seeing as you like numbers you probably would like a real world use case for those branches

Let me give you an example of a small-middle sized Symfony2 PHP project I've been working on.

If you have a project going on for 6-9 months developed actively by 5 developers in agile (scrum) manner with a client demo every two weeks you might want to have branches:

• per user story (on tightly integrated user stories this might be a bad idea), around 50 branches total, think of them as feature branches
• per developer (on demand, if developer needs to work on something for a while), they come and go, but usually developers have less than 3 in this kind of projects. Some of them don't use public developer branches at all and keep their dirty branches to themselves
• experimental (unlimited number of branches for research purposes, for example different algorithm or library used in module), about 7 branches as far as I remember
• per sprint (merged from user stories, helpful for demoing), around 10, these we're our staging/stable during initial development. Why not tags? Tags too, but branches because it's easier to apply a hotfix.
• hotfixes (usually short-lived, isolated for easy cherry-picking), 3 tops ;)
• misc (usually on-going system-wide features and/or 2-3 people team branches), around 10

As you can see there isn't an exact number here either. I've done several projects of this size and most of them had about 70-80 branches (20-30 without user story branches). If they are organised in a logical, clean way the code repository is easy to browse.

With git consider also rebaseing instead of merging, so you won't get merge bubbles (check out this article http://stevenharman.net/git-pull-with-automatic-rebase ).