Why branches are bad

Ok i’m not going to beat around the bush with a long intro into source control, why we use it, etc. Branching, in source control systems, means to fork/split development concurrently in 2 branches of code, from a common root.

This is bad. Why? If you consider that you should commit your changes to source control often, which is a recommended practice, then you should

    fear

huge change merges, since they should be seldom. How does this relate to branching?

Branching is most commonly done for 2 reasons. a) because you want to push hotfixes/patches of the current production build out, at a moments notice and you may introduce incompatible changes into your main line of source control during an iteration of development. So you can do branch development (iterations on the branch, merged when you deploy to production at the end of an iteration), or do main line development where you create a branch for every production release (any hotfixes are released on the branch – merge changes at the same time).

The problem here is an iteration may be 1 week, 2, or 4, or 8 or 12 weeks! How can you assume you will be able to safely merge two versions of code modifies over 12 weeks? You can’t (or you wouldn’t want to!) Merging big change sets of code is a bad practice, is error prone, and is basically begging for something to break.

It is also a hassle for planning of releases, for developers and testers alike – “what version of code am I testing?” “which project/branch do I check into?” the list goes on. It also introduces more context-switching, which we know wastes time. For an analogy of context-switching, consider the ALT-TAB to switch processes in Windows, imagining it takes 15 minutes each time… ouch!

So what is my grande opinion? Don’t branch? Well no. That’s purist talk. But almost πŸ™‚ Branch seldomly, and don’t branch for long (eg. 2-3 days until a week, preferably merging changes daily or whenever possible.)

But why branch at all? Ideally, you don’t need to maintain a branch, if you hide your new features perfectly with feature tagging and ensure continuous integration and continuous delivery then there is no need.

But sometimes, yes sometimes, there are fundamental changes (to a horizontal layer in the code) which cannot be controlled by feature tagging or configuration options, or in a case where old feature set cannot compatibly co-exist with new feature set as they conflict. Here you need a branch 😦

The only other time I can consider branching valid is if you are branching without the intention of merging back, but want to maintain a compatible root (eg. if you fork development to experiment in adding some features, prototyping etc).

Anyway, hope that’s shed some light on souce control branching in a realistic manner.

Advertisements

2 thoughts on “Why branches are bad

  1. We are running 2 week iterations in our agile project.

    The 4/8/12 week iterations reference are more towards traditional ‘waterfall’ projects which only do production releases every 4/8/12 weeks. Unfortunately πŸ™‚

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s