How To Avoid Merge Conflicts

Merge conflicts are every programmers nightmare when collaborating with other developers on a project using git. They are bound to happen as long as you have different developers working on a project. They take time to fix and are darn annoying. Resolving merge conflicts could takes up precious man hours with teams that are very active. It’s usually a sign that there is poor communication and coordination among project members if they happen frequently. In the case were communication is pretty good but every now and then a merge conflicts crops up, is the subject of this article. What we want is to cut all instances of merge conflict if possible. Below I list steps to avoid merge conflicts all together.

Use A diff tool

Its always a good idea to compare branches with a diff tool this can help spot potential trouble spots before merging. To use a diff tool you need to configure git to use a diff tool like so:

$ git config –global diff.tool <diff-tool>

The command to diff two branches is:

$ git difftool  branch1 branch2

A diff tool needs to have been set before you run the above command. Diff tools can also be used to easily resolve conflicts during a merge conflict. Diffing two branching before a merge goes a long way in avoiding merge conflicts.

Use git fetch

Doing a git fetch as opposed to a git pull on origin can save you a load of headache in the form of merge conflict. Unfortunately many graphical tools for git only perform a git pull. A git pull consist of a git fetch and a git merge, which means you don’t get to inspect the changes before they’re merged into your local branch. Doing a git fetch gives you an opportunity to do a git diff between your local branch and the remote branch spotting potential conflicts in the process.

$ git fetch

Personally I use a diff tool called k-diff3 to compare branches, it gives a nice graphical display of the changes between the branches, there are numerous diff tools in the wild if that’s not to your liking. After inspecting the various changes and communicating with the developer who made them for any changes not clear then, you can go ahead and merge the changes into your local branch. At least with this approach majority of the merge conflicts can be resolved even before the actual merge.

Use git rerere

If you’re developer who likes to merge daily or maybe more often. Then you’ll encounter a situation were you keep resolving the same conflict again and again. Then git rerere is the solution you need. It means reuse recorded resolution. Basically it records a merge conflict that has been resolved and reuses it again when that merge conflict happens again. This means that we don’t spend time solving recurring merge conflicts. To use git rerere it needs to be enabled through:

$ git config rerere.enabled true 

Once it’s enabled then if there is a merge conflict of the same scenario that has been been previously recorded rerere automatically resolves it for you.

Conclusion

If merge conflicts keep cropping up then it’s usually a sign that communication and coordination is poor within the project team. In situations like this none of the above solutions would work fully, until coordination and communication is improved within the team.

Comments

[Boris Modylevsky]

I agree that conflicts can be a nightmare. From my experience most of the conflicts can be resolved automatically using proper diff and merge tool. I use SementucMerge which understands the changes and provides automatic merge if possible.

[Hunter L. Allen]

What about this?

$ git fetch
$ git rebase -i origin/[target branch]
$ git push --force-with-lease

While these tools are good, the best way, in my experience, to avoid merge conflicts is to simply rebase your branch into your target branch. I usually do this once a day.

[Samuyi]

Well i think that flow is really good. Especially when you're pulling from remote branches.

[Jesse Phillips]

I totally understand that merges can get complicated, and rerere looks like a good tip; what I don't understand is how a diff is different from a merge conflict. Am merge conflict is generally handled by a diff tool.

[Samuyi]

a diff shows you the differences between revisions of the same file. It helps you compare files. Merge conflict happens when you try to merge versions of the same file and git can't automatically pick which version to go with based on it's three way merge algorithm. Therefore it's needs some kind of human intervention to resolve the problem.

[Jesse Phillips]

But how does a human intervene, I use a diff. Diffing two files also does not change the fact that a conflict exists and any action to combine changes of two files is a merge. And the article was about avoiding them.

[Samuyi]

The diff helps to spot conflicts right before they happen. You can then do a

$ git merge -s ours branch2

to use your changes.
or

$ git merge -s theirs branch2

to use their changes.

With this there is no conflict since you have inspected the changes and told git how to resolve the conflict. In essence you have told git what to do before any conflicts occur, since you saw them before hand.

[Jesse Phillips]

From my perspective the conflict still exists. The difference is that the tool did not tell you about it, you identified it yourself and instructed git how to resolve it.

[Jesse Phillips]

I also would not generally recommend those commands for resolution during a merge multiple conflicts can occur and which side you desire changes based on the conflict, and this ignores a common desire to accurately merge the two changes.

[Mac Siri]

Holy crap I wish I came across git rerere awhile ago. Had to resolve some weird dependencies conflict over and over again. Thanks for sharing!