Posted by: jsonmez | June 4, 2010

Simple Branching Strategy Part 1: Back to Basics

Source control management has always been one of those sticky topics which always causes many questions.  Many veteran programmers are baffled by the in-and-outs of branching and merging.  And for good reason; it is a difficult topic.

I’ve been around in many different organizations.  I’ve been the person who was told what the SCM strategy was, and I have been the person who designed it.  I’ve seen it done just about every way possible, and after all that, do you know what I think?  (I’ll give you a hint, it’s the name of this blog)

Keep it simple. Working directly off the trunk is by far the best approach in my opinion.

It almost sounds like heresy when I actually type it onto my screen, but if you’ll bear with me for a moment, not only will I show you why I think this is essential for an Agile process, but I’ll show you how to make it work.overview_morphology_branching

Continuous integration is the root

If I had to base my reasoning on one solid argument, it would be the value of continuous integration.  I blogged about the value of CI and best practices in the past.  I am a pretty big advocate of CI.

As a software development community as a whole, I think most of us can agree that CI is good and provides real value.

What is Continuous Integration then?

Continuous Integration is a software development practice where members of a team integrate their work frequently, usually each person integrates at least daily – leading to multiple integrations per day. Each integration is verified by an automated build (including test) to detect integration errors as quickly as possible.

Martin Fowler

So the idea here is to integrate as soon as possible, the faster the better.  If something is going to break, we want it to break sooner rather than later.

The best way for this to happen is that whenever I check in my code it is instantly integrated with everyone else’s code and we build and test it.

This is a change from the old way of doing things, in which I am working on my code in isolation for some period of time and periodically I show up with a bunch of code and merge it all together.

The only practical way to have continuous integration is to have everyone working off the same branch.  It doesn’t have to be trunk, but it has to be the same branch.  Sure, there are some ways to have people work off different branches and automatically merge them when they commit as a trial integration, but that is a large amount of effort, and it can’t handle conflicts.

Agile principles

One of the “big dogs” in Agile is collaboration.  Collaboration is pretty important.  Working on separate branches tends to go against this idea.  I know you can still collaborate when you have separate branches, but it is more likely that you won’t.

In general I have found that software developers in particular are the kinds of people who will go off and do their own thing if given the chance.  It is not a bad thing, but it means that we need to set up developers to collaborate.  If your process isn’t explicitly fostering collaboration, it probably won’t happen (at least not as much as you would like it to.)

If we are all working on the same branch we have to communicate.  We have to work together to accomplish a goal.  I can’t just work in isolation, because what I am doing affects you, and what you’re doing affects me.  We have to talk about it.

I’m more likely to watch your code come in and say “hey, where is your unit test, bub?”  You’re more likely to watch my code come in and say, “is there a reason you’re not using superWidgetX to solve that problem?”

If I check in some junk and break the build, everyone is impacted.  This might seem like a bad thing, but it fosters a team mentality instead of an individual mentality.  Think about boot camp (or at least what you have seen on TV.)  What happens when one guy screws up?  EVERYONE does push-ups.  Why?  To build a team, a team mentality.

I have found in Agile processes like Scrum, the best quality work is done when developers are paired up working on a backlog item.  This isn’t impossible to do with individual developer branches or feature branches, but it is much harder and less likely to happen.

Keeping it simple

One of the central themes of my blog… of my life… is keeping it simple.  Simple is good, it makes everything easier.

I am notorious for walking into an organization and ripping out all the ridiculous process that provides no value, and putting in very simple and lean process in its place.  It is in my nature.

If you have ever spent some time in what I like to call “merge hell”, you’ll understand what I am about to talk about.

I have been working with source control for a very long time.  I have been the “merge master”, merging huge numbers of branches together on large projects.  I have worked on developer branches, feature branches, release branches and everything in-between, and I still can’t get it right!

Don’t get me wrong.  I know the theory behind it, I know how to do it.  But merging can be so complicated at times that the chance of making a mistake is very high.

You really have to ask yourself a question here: “Is all the overhead you are incurring from doing your complicated branching and merging strategy resulting in a real value that does not exist over a more simple strategy?”

My general rule of thumb is, never branch unless you have to.

A simple Agile branching strategy

In my next post, I will show you what I think is the most simple and effective branching strategy.  A strategy I have effectively used in the past and have developed over time.  I’ll sum it up briefly here.

  • Everyone works off of trunk.
  • Branch when you release code.
  • Branch off a release when you need to create a bug fix for already released code.
  • Branch for prototypes.

That’s it, stay tuned for next time when I talk about how to make this simple branching strategy practically work in your Agile environment.

As always, you can subscribe to this RSS feed to follow my posts on Making the Complex Simple.  Feel free to check out where I post about the topic of writing elegant code about once a week.  Also, you can follow me on twitter here.



  1. […] Simple Branching Strategy Part 1: Back to Basics (John Sonmez) […]

  2. Why branch for a bug fix in the release branch? Do you mean “branch the trunk” in that case or the existing release branch?


    • I’ll explain it in my follow up post on the simple branch strategy. Basically you want different bug fixes from a release branch to have the ability to be independent.

  3. […] Simple Branching Strategy Part 1: Back to Basics – John Sonmez looks at the key issues surrounding branching strategies when working with Source control management / version control systems in this back to basics article series. […]

  4. […] Branching Strategy Part 2: Implementation In my previous post, I talked about the idea of having a simple branching strategy and why I prefer one where everyone […]

  5. The key problem I’ve found with the process you’ve described, is that developing off the trunk means one of two things. Everything every developer is working on is released with the next release, or developers don’t check-in often because they’re features aren’t ready to be released (undermining the protection SCM provides).

    • Your right. In my next post, I talk a bit about how to mitigate those problems.

      Everything every developer is working on should be able to be released in the next release, unless there is a specific reason why not. In that case, you should create a separate branch. But that should be the exception, not the rule.
      If you can break down feature development into small iterative steps to getting it done, (like crossing a stream, leaping from rock to rock), you can always check in good quality releasable code. Even if the entire feature isn’t done, it shouldn’t negatively impact the system.

      With that mentality of trying to integrate often, you can encourage developers to check in every time they make progress on a feature. When I am working on a feature, I will make small steps checking in many times throughout the day. Each time I make a step, I am able to check in a fully working version of the system. It really isn’t as hard as it seems to do that.

  6. […] stumbled across these blog posts:  Simple Branching Strategy Part 1: Back to Basics and Simple Branching Strategy Part 2: Implementation.  I like the posts because it talks about […]

Leave a Reply

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

You are commenting using your 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


%d bloggers like this: