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

6 thoughts on “Merge conflicts”

1. Okay, First Off, i agree with the fact that those Kinds of conflicts Steel A Lot of Time. I use SVN in the Company And yes, we’re trying to avoid conflicts while we’re working on our project.

   And that’s exactly the Point. Using SVN And making a Lot of Meetings because of Many different Communication Problems, is in my opinion Not the right Approach for a certain Solution.

   There are a few buzzwords for how to avoid all these Problems wirh Communication And conflicts while using a VCS:

   - Git
   - working asynchronously
   - no Meetings
   - Not pulling developers Out Off the Flow

   Let me dig into These points. If you’re using Git you don’t Ever have These Kind of suicide Feelings when trying to Merge a Branch back to Trunk. Branching, merging, all This stuff which is a pain in the Ass when working with SVN, is damn Easy to do in Git. Merging in Git is a very powerful Thing that you have to use if you wanna be productive. And its okay, because its Easy.

   Working asynchronously means That you do your work. There is no Meeting which Pulls you Out of the Flow. Meetings are Time steeling. If you wanna Talk about Things, do it via Email, send pull requests And use These as a discussion Base.

   So in my opinion, all the Things you pointed Out there are very Easy to avoid, if you’re Doing it right.

2. “Talk to your product manager
   Talk to your project manager”

   I would like to add something: Sometimes, your team’s and/or the other team’s agile tester may know about it, so:

   Talk to your tester

3. hi björn,

   i agree with you, that talking to colleagues is very important.
   however in your post you imply that talking to the whole company is neccessary to prevent merge conflicts.

   i don’t see why you expect from a project or product manager to have enough technical expertise that they can see that 2 different stories affect same parts of the source code?

   in my opinion the first and simplest thing to avoid merge conflicts is to commit (and even more important) update your local code as often as possible with the changes your colleagues commited. the chance for merge conflicts decreases on every update you do. if a conflict occurs it is often so small that it takes me a minute to solve it.

   nevertheless your solutions are good and be worth discussed e.g. in a retrospective. but i see that taking only as an additive not as the main solution.

4. ok, normally I would’ve stuck with a tl;dr here, but I don’t even know where to start.

   Your article is factually wrong. The whole concept your describing here is absolutely way off what merge algorithms were actually built and intended for. It’s like using a fruit knife to explain the ability to cut wood for a chainsaw.

   Let me explain: “CVS, SVN or GIT, merging is a daily task.”
   If you told that to Linus or the author of any other first or second generation DVCS theyd rip you apart.
   First of all merging and CVS is, well, hehe … SVN was set out to fix that but still has other conceptual flaws.

   Now lets go to GIT, GIT was made to merge 1000s(or maybe it was hundreds) of patches each day from peers. The whole concept is trust. Linus trusts that the peers hes merging from only merged stuff from trusted peers or checked the code themselves or built it themselves.

   Already you see a conceptual conflict here. How does that guy manage to merge tens of thousands of lines of code without conflict from people he doesn’t talk to? Already you should be asking yourself maybe there is a problem with what I do.

   But ok, you got a conflict. Git developers have spent hours and hours on how to make the process less painful.

   If you keep having problems with conflicts on your codebase, the solution is not talking more to product managers, testers, management etc. The solution is to rethink the way you work. Because it sounds broken. You need to talk less and get more done.

   Here are 2 reads on that topic
   http://scottchacon.com/2011/08/31/github-flow.html
   http://iwata.github.com/blog/2011/11/21/git-royale/

5. Thanks for the feedback so far.

   @Pascal: “Pull requests” are a good point. The times I refer to in the article, were times where we did not work with pull requests. Now we use github so this may improve.

   @Karin: Good point ;-)

   @Marco: I agree, frequently merge your code avoids most of merge conflicts

   @Reza:
   To clarify things, I am not accusing GIT or Linus for making me fix merge conflicts.
   Furthermore I am aware of merge workflows very well ;-)
   My intention was more to investigate whether merge conflicts can point to organisational issues or can be avoided at all.
   But I got your point “maybe there is a problem with what I do”. Thats missing in the article itself. Thanks also for the links.

6. Your posts sites stories are really cool. Good luck with your site in the future.