Merge conflicts

First of all, what is a merge conflict?

When working with a “version control system” (VCS) such as CVS, SVN or GIT, merging is a daily task. Your developer colleagues also work on their features and commit code. To keep your local version up to date you need to “pull” and “merge” their work on a frequent basis.

But what causes a “merge conflict”?

There can be several reasons for this. Here are the most common:

Empty lines

This is the most trivial one. Let’s look at an example involving a .js file:

796:     function foo(){
797:       fooFoo();
798:     }
799:
800:

Now I make changes within the file. Personally I dislike empty lines, so while already working within this file I decide to erase these trailing empty lines so that the end of the file looks as follows:

796:     function foo(){
797:       fooFoo();
798:     }

My colleague then works on the same file but his mission is to create an additional function which he decides to append at the end of the file. Afterwards the file looks like this:

796:     function foo(){
797:       fooFoo();
798:     }
799:
800:     function bar() {
801:        barBar();
802:     }

Your version control system no longer knows what’s right or wrong, and therefore requests you to manually resolve the merge conflict as it can’t decide which version is correct.

Changing the same lines of code

Let’s assume the following situation again:

796:     function foo(){
797:       fooFoo();
798:     }
799:
800:

In your current project you add a condition:

796:     function foo(param){
797:       if (param) {
798:         fooFoo();
799:	  }
800:     }
801:
802:

Whereas your colleague changes the function call in another way:

796:     function foo(param){
797:       fooFoo(param);
798:     }
799:
800:

Again, your VCS doesn’t know which change should be retained after the merge so this results in a conflict. Therefore you as a developer are requested to solve it.

Amongst other variations of the above cases (where what you changed in your branch was deleted/ edited by someone else in the master branch or vice versa), I’d like to round off this part by sharing my favorite case:

If we start with the same situation as before:

796:     function foo(){
797:       fooFoo();
798:     }
799:
800:

Where you’re working on a long-term project and e.g. add another call:

796:     function foo(){
797:       fooFoo();
798:       callSomethingElse();
799:     }
800:
801:

On another project in your company there is an A/B test where one feature is tested against another. All of a sudden the code in master looks like the code below while you’re still working on your local branch:

795:     <? if($user->abTest) { ?>
796:       function foo() {
797:         fooFoo();
798:       }
799:
800:     <? } else { ?>
801:     //new variant to be tested against the old one
802:     function boo(){
803       booBoo();
804:     }
805:    <? } ?>
806:

So what? The function you edited was NOT changed by the other commit.

But it was indented! That is already enough to provide you with extra work by having to determine what happened there and, even more importantly, determine whether the rest of your changes will also work with the new a/b tested variant.

In other words: It’s a lot of work!

So talk to the colleague who caused your merge conflict

Firstly, at least two developers are editing the same code, where one of them is editing something specific. The problem here is that it’s no longer clear whether these edits will be committed correctly. That in turn means that both developers have to sit down and work out how the code they’ve both been working on can be stitched together if the one who caused the conflict in the first place isn’t able to retrace it all.

Conflicts can’t just be “quickly sorted out” if the merge conflict involves large blocks of code rather than just a few lines. Maybe entire templates suddenly disappear that you were trying to access…

Talk to your product manager

Merge conflicts can also mean, however, that something is at sixes and sevens with the product roadmap. Why have two completely different teams decided to edit the same code at the same time? Something like that should be addressed at product level in advance.

Talk to your project manager

Having said that, maybe the project management team has slipped up. If they didn’t coordinate with one another properly, a “racing condition” may occur in which there’s a winner who can simply commit his changes while a second developer is stuck with all the merge conflicts and therefore “lost the race”. This is something that communication at product level could have prevented.

Drawing conclusions from merge conflicts?

If merge conflicts occur on a frequent basis and therefore take up a lot of developers’ time, we need to ask ourselves what we can learn from this? The first question is at what point does the project or source code become so large that it’s no longer possible to coordinate things internally so that the teams don’t work on the same bit of code at the same time? This would of course involve a lot of meetings in order to build up a sufficient information structure in which no single team has an influence on the other.

This then gives rise to the question of at what point merge conflicts are more effective or even inevitable. In an ideal world, all teams would coordinate with one another to make sure that developers don’t get in each other’s way. But that would of course involve a lot of meetings, so we need to ask ourselves which would actually be more work – the merge conflicts or all those meetings?

Talk to colleagues

XING developers have daily stand-up meetings where they let each other know what they’re currently working on. This has already helped to avoid a number of conflicts such as merge conflicts before they happen. Having said that, daily stand-up meetings still aren’t a sure-fire way of preventing merge conflicts from happening, so we simply have to live with that.

Here at XING we have a rule in place that when a merge conflict occurs, every developer has to help out when it comes to fixing the problem, and those involved have a duty to report. This of course brings us back to the critical point – communication.

We’re curious as to how other companies deal with merge conflicts. So feel free to let us know how many people work at your company, how many developers you have, and whether you have also experienced merge conflicts in the past.

About the Author

This entry was posted on Tuesday, December 6th, 2011 at 09:45 and is filed under Everything else. You can follow any responses to this entry through the RSS feed. You can skip to the end and leave a response. Pinging is currently not allowed.