Update: This is an old article that helped us at the time, using a centralized version control system (Subversion). We created our own branching strategy, and in essence, came up with trunk based development before we really knew it already existed. For the record: I would heavily advise against developing your own branching strategy. The issue with making up your own branching strategy is that, like most not-invented-here solutions, you’re probably not going to be smarter than the community. Choosing a well-known strategy means there is more documentation and support, and it’s easier for new developers to get up and running because they will probably already be familiar with it.

In our team, we’ve recently changed our source control strategy to what’s now being called ‘trunk based development’. This has reduced the amount of merge-headaches we were having.

In the past, we used a form of branch-per-feature with only one branch. We would have a trunk and a development branch (we’re using Subversion). Coding would be done on the development branch, and when a story/feature was finished, it would be merged to the trunk. After the merge, a new development branch was made. The trunk was, in effect, always releaseable.

At least, that was the theory. This didn’t really work in practice:

• sometimes a feature can’t really be released without the next story
• bits and pieces of the next story would have been implemented before the previous story had been finished (otherwise developers would be sitting around, waiting for the merge before committing)

More importantly, this slowed us down because:

• there were conflicts when merging (when a fixes branch touching the same code had been merged in the trunk)
• it takes some time to merge, build, commit, delete the old branch and make a new branch (meanwhile, teammembers can’t commit code to the old branch)
• this is inherently error-prone, as conflicts could be resolved wrongly, (re-)introducing bugs, often only discovered when the code was already in production

Finally, there was no need for our trunk to always be releasable, because we know when we’re going to release and with any modern source control system, you can jump back to certain revisions.

Curing headaches

Switching to trunk-based development is easy and we haven’t looked back since. The point is:

• Develop and commit to the trunk
• Make tags from the trunk
• Bugfix branches are made from the tag, but are merged to the trunk again of course

The only problem you can have, is at that moment just before a release. There are two smaller tasks that need to be finished for the tag, but other developers want to start with the next story. This next story is not allowed to be included in the tag.

The solution is simple: make a branch to finish the work for the tag. Finish the job, make the tag from this branch en merge the changes back into the trunk. No need to remove this branch as it can serve as a bugfix branch.

Here’s a colorful diagram to make this post look professional:

In the end, this makes our development track more fluent, less stressful, less complicated, and hasn’t given us any problems.

At the moment we researched this, there wasn’t very many information to be found. But these are the articles we based our decision on:

• Feature Branch – by Martin Fowler
• Branch By Abstraction – By Paul Hammant
• Some Problems with Branch Based Development, And Recommendations – By Jonathan Andrew Walker
• Trunk Based Development Explored – Slideshow by Agile Brazil
• Branch vs Trunk Based Development