Code Branching and Merging

At work, we've recently started using multiple branches in our configuration management tool. We've had to do this to accommodate simultaneous development on two different major initiatives (one if which is currently in test and one in the early stages of development) along with maintenance releases that the business can't wait for anymore.

In the past, we've had a more simple branching model, where we do a major release off the trunk, and then create a branch for the inevitable "point releases" that we would do to fix things found in the first build. This allowed us to continue development on other projects while only releasing bug fixes in the point builds.

This has been quite a learning process for our small team. I'm actually glad our team is so small; otherwise I'm not sure this would work at all. Over the last week, we've been working on the branch that is already in production, while the QA group tests the most recent major build, which is one higher than the branch in production. As we've done that, we've had to check in our changes (once they test out), then merge them to two other branches, and test those. Finally, today, we did the build on that branch. At this point, we merged our changes from the past week into the trunk. In theory, everything should be relatively in sync, except for new development on the major initiative branch.

To get to the point of this post, here are a few things I've learned since we started doing this:

• Communication is key. At first, some team members were confused over which branches to check their changes into. Luckily, this was quickly resolved with a couple of email exchanges.
• Merging can be hard. One of our developers is not as familiar with branching and merging as the others. This developer initially just copied the changed files into the other branches, rather than using the merge tool. This led to code that didn't even build, let alone run correctly. Once it was explained how merging was supposed to work, this was resolved.
• A good merge tool is required. In an earlier post I recommended WinMerge. That tool has made merging far less painful than what it might have been. Trying to merge files by hand or even using the tool provided with StarTeam is not something I would like to have to do.
• Even a simple change is no longer simple. With this new model, we have to test our changes in the branch we're working in, sometimes for all the countries we support (we currently do business in 7 countries, with 4 different languages). Then, we have to merge the code to each branch and repeat those tests. This means even a one or two line change can easily eat up 2-3 hours of time.
• Code separation can really save the day. During this iteration of changes, we were lucky that we had no merge conflicts. Part of this is due to the fact that our system is fairly large, so there are a lot of files. It also helps that we have the system architected in layers, so the business logic is separate from the presentation logic and the data access layer. That made it far less likely that two developers would be in the same section of code at the same time.

Branching and merging are difficult at times, but they eventually come up in any organization that releases software, even if it is only to internal users. The best thing to do is come up with a plan, document it, and then stick with it, at least as long as it makes sense. You should, of course, revisit it from time to time and make sure it is still working for you, and make adjustments if it isn't.