This is the second part of the series of articles about merging. In the previous post I talked about automatic merges and how the version control systems solve the conflicts for you. But, whenever you start thinking about merging you'll say: "hey, what if we touch the same code?". I'll try to answer this question here.

You're in trouble: manual conflicts

Developer's life can be exciting and full of challenges, but it is not easy. So, eventually you'll face a situation like the one depicted here:

Figure 3. A conflict on the same code block

Yes, know we've modified exactly the same code in one of our changes on the file, which makes things much more complicated.

Now you can say "the tool can't know the right solution!".

And you're right. But, as I told you, the merge tool is not a wizard's device; it is just a programmer's tool. So, use it correctly and it will make your life much easier.

Figure 4 shows a merge tool in action letting you decide what to do with your manual merge conflict.

Figure 4. Merge tool solving a conflict

Under these circumstances the tool will always prompt the user. It will still save you precious time because it directly focuses you on the problem, but you'll have to make the decision yourself.

So, the merge tool will help you with automated conflicts not even asking you if you don't want to (and honestly, it is the right choice) and will ask you for help whenever it finds a manual conflict, which is basically a code fragment with changes made by two developers at the same time.

The rule of thumb is very easy and will help you trust the tool because there's no complex code analysis behind: just looking into the lines of code: if only one contributor changed the fragment, it is an automatic conflict, otherwise, it is not trivial and the tool will ask.

2-way and 3-way merging

What's all this fuss about 2-way and 3-way merge tools? What are they all about? Ok, that's what I'll be explaining in the next paragraphs: it basically depends on the number of file versions you consider for your merge operations.

So far, what you've seen is a 3-way merge in action:

• You have the original file: it is the file as it was at the beginning before a specific set of changes is performed by our developers.
• Then you have the file you have modified (remember the previous samples).
• And finally the file I've modified.

The result file is the one created after the changes are combined, the one at the bottom at Figure 4 (some tools prefer to hide the base file and just show the result one).

I didn't explain 2-way merge yet, but it is not very complicated: it doesn't consider the base file for the merge.

Is it better? Simply put: no, it isn't. 3-way merge knows what you've added or removed to a file while 2-way merge can't because it doesn't know how the file was at the beginning.

But, still, I've found developers who seem to be more used to 2-way merge tools. Let's try to figure out why.

Let's go back to the original Java file, make a couple of very simple changes, and try to merge them with a two-way merge tool. Check the results on Figure 5.

Figure 5. Running a 2-way merge tool

See the problem? Basically, at each difference the 2-way merge tool won't be able to decide whether it is modified or remove code, so it will always have to ask you!

This is good for the paranoid but, believe me, if you've to manage a good number of merges, you'll end up wasting your time.

The same two conflicts would be automatically solved by a 3-way merge tool.

Of course, there's a remark here: you can only use 3-way merge with a version control tool handling your code. Otherwise you won't have access to the base file unless you've a very good memory or a crazy naming convention to keep your old files...