Branch per feature: What are the actual benefits (and risks)?

Question

I've read quite a lot of posts lately about different branching strategies (e.g a lot of links from To branch or not to branch?), and while almost every article explains on how to do this or that strategy they rarely explain the why.

Currently our team is investigating whether or not to switch to "feature branches". We're currently using a "everyone commits to trunk" model and we have release branches, which we use to do hotfixes to previous releases. All in all, this model has worked very well in the past. So actually I'd say - if it ain't broken, don't fix it.

However, there might be a point that I'm missing, so I'd like to ask: What are actual tangible benefits of using a feature branch strategy over "everyone commits to trunk"? What are the drawbacks of feature branches in your experience?

Answer 1

The advantages are obvious - you work on features independently, and so they never affect anyone else's work until it comes time to merge. You can do code reviews and targeted testing on the feature branch without holding anyone else up if there's a problem.

The disadvantages: firstly, you do have to merge and while that's not a problem with tools like Subversion, git or similar, it can be a right pain with some tools. You also have to consider that even with tools that support merging well, its not necessarily a pain-free process. If you have to merge binary files (eg images, icons etc) or you're merging files that have also been changed, then you will have to spend a little extra time managing the merge.

The other disadvantage is that you might add something to a feature branch that you'd like to use, you either have to merge that feature branch to your current one, or wait for it to get merged to trunk (and then merge it), so there is scope to get a little out of date with regard to other work.

Both disadvantages aren't particularly onerous as long as you don't expect feature branches to be worked on and then left for a long time before merging back to trunk. I think they're probably a better way of working compared to the develop/main/release model, and especially to the 'work on trunk' model typified by tools like Sourcesafe.

That said, there's no reason not to fix something that isn't broken. If your team is suited to your current process and you have no issues with it, then continue to use it.

Answer 2

Assume that you're working on a feature in a seperate branch. Then for some reason, you need to make a completely unrelated change somewhere else; say you're fixing the build.

With feature branches, you can just commit your current work in your branch, switch to default, make your fix and switch back.

Without feature branches, you either have to very selectively choose which files you want to commit (which can go wrong very easily), or you have to stash your current work (but stashes can be finicky), or you have to just push unfinished stuff (you can imagine potential consequences).

---

Another useful scenario is where you have to do some work that would touch a lot of the code, something you'd be working on for some time. Usually these are big refactorings.
If you do this sort of stuff in a branch, you can work in isolation, not disturbing others with your changes, but still frequently commit and sync with the default branch.

Branches provide a very good safety net and I can tell that we've had a lot less merge conflicts and general friction since we started using them. But your mileage may vary.

Answer 3

It depends what source control system you are using. In some distributed source control systems like Git and Mercurial branches are very lightweight and I usually create branch per feature while using one of these systems. It is very convenient and relatively easy to maintain. You can easily make different experiments with your source code and share these results to others.

Also branching is useful when you are working on large feature and need to perform some support tasks with existing code. You can easily switch from your feature branch to default branch, make fix in default branch, switch back and continue working on your feature. Of course you should take changes from default branch periodically.

However, some source control systems do not support lightweight branches and copy entire directory with source code. In this case branching per feature is really pain when your codebase has large size.

Answer 4

The main advantages are you might have too large a team size, or want to work too many hours in the day, to keep busy by only delivering the required functionality.

This problem is solved by adding long-lived feature branches. This multiplies the effective size of your code base by the number of such branches, creating adequate work for everyone on the team. And unlike simply adding more features, this avoids complicating the software, or losing opportunities for future revenue. Everyone is busy visibly typing (or at least clicking) all the time, so noone looks bad to management.

Another advantage is it avoids having to learn how to properly use a modern distributed version control system such as git to adapt to different circumstances such as an unplanned context switch, the need to patch an old release, or back out a bad change. Instead, one technique fits all contingencies, and everything can be pushed centrally just as if you were using a faster Visual SourceSafe.