There are quite a few ways to resolve conflicts in git, whether it's through the command-line or a GUI. In this post, I'm going to offer an opinionated solution using the command-line and, more specifically, using a tool called vimdiff (because I'm most familiar with the Vim interface). If you find this post helpful, head on over tomy blog and check out some of my other posts!

Set up Git config with your tool of choice

The first thing you'll want to do is configure git to use themergetool you're most comfortable with. There are a number of options to choose from, including emerge, gvimdiff, kdiff3, meld, vimdiff, and tortoisemerge. For a complete list of tools and settings, simply rungit mergetool --tool-help in your terminal. In this post, I'm going to use vimdiff. Now, I could do this by runnninggit -t vimdiff, which would configure it as my tool for this session only. However, I want git to always default to this tool for any future conflicts.

So, the first few commands that we'll run are:

git config merge.tool vimdiffgit config merge.conflictstyle diff3git config mergetool.prompt false

The first command specifies which tool is used by the git-mergetool. The second command specifies the formatting of conflicts in your terminal. Setting "diff3" in this instance adds the original text to the conflict display, but leaving it as default and omitting the second command is fine as well. Finally, the last command just ensures that the user is prompted before the merge resolution is executed.

Starting the merge tool

Executing thegit mergetool command will run the mergetool and you can begin resolving conflicts.

Your terminal should now display an interface similar to the format in the image below.

As you can see, there are four sections in this UI. Thelocal section is the file from the current local branch. Thebase is the common ancestor between the local and remote commits. This is essentially what the file looked like before either commit was changed. Theremote file is the one you are merging into your branch. Lastly, themerged file at the bottom is the result of the conflict resolution and what will be saved in your repository after you execute the resolution.

You can navigate between the four areas of the terminal usingCtrl W to move between windows, orCtrl W +J to move directly to themerged window. For other navigational commands,visit the vim docs.

Edit the files

Once you've navigated to the window that you want to edit, press thei key to insert text in Vim. After you're finished making the changes you'd like, press theesc key to exitinsert mode and entercommand mode, and you should see those changes reflected in yourmerged section. If not, simply type:diffupdate and hit enter and the UI should update to show your merged copy.

If this seems tedious and you would rather take a complete copy of either thelocal,base, orremote files, you can run the following commands.:diffg RE gets the entire changes from theremote copy,:diffg BA from thebase copy, and:diffg LO fromlocal.

Save your changes

After you're satisfied with the changes you made, and the merged copy reflects what you were after, it's time to save and commit the changes.

Entercommand mode by pressingesc, and type:wqa. This command will write, save, and quite all filles within Vim. You are now ready to commit your changes using the well-knowngit commit -m "My Commit Message" command. Vimdiff will create a few files for you during the resolution, most ending in a*.orig suffix, but to get rid of these files simply rungit clean.

All finished

That should do it. Assuming you had no other conflicts, you should now be ready to push your changes. If there are more, feel free to use the same process we just went over to resolve any outstanding conflicts. I originally decided to write this article as a reference guide for myself, but I hope I've helped a few other frustrated devs stuck in conflict purgatory along the way 😉.