As a professional programmer you're familiar with a variety of programming languages, you know by heart the basics and not so basics of data structures and algorithms, you are an expert working on your favorite IDE, you master software patterns and you're aware of the newest trends in agile methods. But there's a useful piece in the programmer's toolbox which is normally more feared than used: the merge tool!

My goal is to remove the fear from merging, so this series of articles will explain, step by step, the very basics of merging and will explore the different merge types, their uses and advantages.

Merging (and not locking, our old and mean friend) is the bais of parallel development, so there's much to gain in our trip...

Fear of merging

So, you write code, don't you? And there's a big chance that you don't develop code in isolation, do you? The code you write for your projects is normally scattered across a number of files. And, according to the Pareto Principle, 20% of the files on your project will receive an 80% of the changes. You can try to trace a bad design smell here, you can try to refactor your code from top to bottom day and night, but, unfortunately, that's just reality: if you and your team work on a project, there's a huge chance you end up editing the same files at the same time.

For a number of projects out there this is a big problem. I've found a number of project managers and software designers trying to avoid concurrent modification wrestling their project plans and software designs. Wouldn't it be better if they were putting such efforts in making better software and finishing it on time?

But, there's an ancestral fear behind this behavior: the arcane fear of merging. "Hey, if you and me modify the same file... we'll have to reconcile all our changes!!". And of course, they assume it will be a painful and error prone process. "So, let's schedule our changes so that only one of us touches the file at the same time". Ouch!

Long ago software development was about lone eagles working alone. Now software development is about new languages, new tools, but at the end of the day is all about collaboration. And, avoiding collaboration doesn't look like the smartest way of getting the best out of a team.

Then, why are we initially so scared of merging our file changes? I find two key reasons:

• Lack of knowledge about how merge tools really work. People tend to think about code merging as some sort of magic process able to understand their code in order to combine changes. They don't believe code can be always correctly understood by the system, and they don't trust merge tools. Of course, under their assumptions, they're right. The problem is merge tools don't analyze or understand the code, they just apply some simple and clever rules to combine texts. The same way you trust your compiler will generate the right machine code, you should trust your merge tool.
• Past bad experiences: merge tools and their big brothers the version control tools, have evolved during the last two decades. Probably you've experienced some awkward issue with an old-fashioned (but still alive) version control system. But if you still believe they're still the same, is like still preferring coding in assembler because you don't trust compilers.

Merging explained: automated conflicts

Do you know how a merge tool works? Let's take a look at a very simple example. I won't dive into the obscure algorithm details but just make a 1000ft flyby.

Suppose we've a piece of code like the one at Figure 1. Then you and I start making changes on the file at the same time. I make a couple of changes at the beginning of the file, and you add a new method below.

Figure 1. Initial code

Merging our changes manually is possible; it is a small file so it will just take a few minutes to do. It will require both of us to carefully look at our changes, but we'll make it.

Of course the picture changes if we've changed not one but 15 files in total, and up to 8 have been modified in parallel. Also, what would happen if, instead of only the two of us, 5 people is working on the code at the same time? Yes, the process is doable, but it is time consuming, error prone and... boring!! I bet you've better things to do than manually combine files.

But, what a merge tool has to do in our previous example.

The tool will find an automatic conflict. Look carefully, our changes don't collide, so what we would do manually would be just copy and paste my changes on the right part of your file or vice versa. It is very simple, but doing manually is error prone. This is exactly what a merge tool will do: just put the two set of changes together, with no possible collision or conflict.

Normally, during a merge, the tool won't even bother you asking to look into such a conflict; it is so simple it can solve it by itself. Of course, almost all the tools out in the market will allow you to set a mode in which all conflicts are reviewed by the user. It will just propose the changes, but you will be the one actually making the decision. Do you feel safer now? Ok, I bet after a week of manually reviewing trivial conflicts you'll switch to automated mode.

The Figure 2 shows the results of the first merge and how a merge tool will combine the changes together to create the result.

Figure 2. Result of the first merge

What's next

Ok, the trip has just started, so there's much more to come. What I plan to cover next is how manual merging works, so you can start trusting there's no easy way to break your beloved code even when you're not combining all the code by hand, because the tool will always avoid dangerous merges.