Introduction

‘Git is a version control system’ – you’ve probably heard this more than enough already. But why does it matter?

Table of Contents

Version control systems are a means of working together with other chefs to cook a fancy dish (collaborating with other developers on a project). How git handles it, is by allowing each individual to merge their set of changes to a main (or master) branch where all the changes are merged into one final piece of something (be it a plugin, a program, or whatever else). Unfortunately, there are cases where you’d get errors regarding merge conflicts. This tends to get awfully frustrating if you’re unaware of the causes for their occurrence and don’t know how to handle them efficiently.

In this article, that is exactly what we’re going to talk about – finding out why merge conflicts are encountered.

Using git status to check for merge conflicts

When working with merge conflicts, one of the most handy commands you’d want to use is the ‘git status’ command. It allows you to get quick insight on whether there are any conflicts currently present in your repository. Therefore, make sure to use the command whenever you’re unsure if there’s any conflict taking place or not.

There are conflicts with local changes

If you have any local changes in a given repository (in the working directory and or in the staging area) the git merge command will fail to execute, and cause a merge conflict to arise, showing the following error message in your terminal when you attempt that:

$ error: Entry '<file>' not uptodate. Cannot merge. (Changes in working directory)

The reason for this is that when you merge in some stuff from a different branch, that could essentially overwrite any local changes that are left to be committed. As a result, git will prevent the merge from being initiated. In order to fix this, you’ll either need to commit the changes you’ve made, or at least stash them temporarily.

There are conflicts with target branch’s files during merge

This is the more practical git merge conflict situation. When you try to merge in a different branch to your master branch that has some similarities between each other (having the potential to cause a conflict), such as some code that occurs in the same line between two files. Git will nevertheless give its best shot to merge everything that is possible, and to the very least initiate the merge instead of stopping it altogether. In such cases, the conflicted files will be filled up with some dividers with the content intended to be merged, but were not possible to do so.

The file shown below is an example of a conflicted file after a merge attempt that contains some dividers indicating the contents that could not be merged:

There are a few things that you might wanna grasp your head round properly.

In between the ‘<<<<<<<< HEAD’ and the ‘=======’ parts, the content which originally existed is stored. In our case, it is the line “This is the second sentence of the file”. And in between ‘=======’ and ‘>>>>>>> <branch to be merged>’’ the content from the file we’re trying to merge (which failed) is stored.

In the following sections, we’ll discuss the two different ways you could work out and resolve the merge conflicts.

Reverting to previous state after git merge

If you wish to revert back to a previous state of your master branch before you attempted the merge in case the files are getting out of order, you can do so with the help of two other git commands. The first command you can use in order to revert the merge and essentially undo it is this:

$ git merge --abort

It’s a safe way to go about the conflicts. If you want the reversion to be one step and would like more control, you can also chose to use the reset command in git:

$ git reset

This pretty much does the same job as ‘git merge –abort’, except that there’s the option to switch back to any previous state of your repository when it was committed. For example, if you had a git commit before you initiated the merge, you can grab it’s that particular commit’s hash ID by using the git reflog command and then passing the ID as an argument to git reset:

$ git reset <commit_ID>

How to resolve merge conflicts

If you don’t want to revert back to a previous state and would like to manually fix the conflicts, that’s definitely the best thing to do, in my opinion. The first thing you’d want to do is remove the dividers as mentioned previously. If I wanted to fix the conflicts in the example file we saw earlier, this is how it’d look like now:

Afterwards, it is all upon you to decide what you’d want to do with the remaining lines. If you want to store all the content together, you can simply save and exit the file. If you want to remove some lines from the original file and replace it with the target file being merged, simply remove them. Once you’ve made sure that the dividers have been remove, git will recognise the conflict to be fixed, and you can finally do a git commit once again the imprint a successful merge commit to your repository:

$ git commit -m “A successful merge commit!”