How do I resolve merge conflicts in a Git repository?

Try:

git mergetool

It opens a GUI that steps you through each conflict, and you get to choose how to merge. Sometimes it requires a bit of hand editing afterwards, but usually it's enough by itself. It is much better than doing the whole thing by hand certainly.

As per Josh Glover's comment:

[This command] doesn't necessarily open a GUI unless you install one. Running git mergetool for me resulted in vimdiff being used. You can install one of the following tools to use it instead: meld, opendiff, kdiff3, tkdiff, xxdiff, tortoisemerge, gvimdiff, diffuse, ecmerge, p4merge, araxis, vimdiff, emerge.

Below is a sample procedure using vimdiff to resolve merge conflicts, based on this link.

1. Run the following commands in your terminal

   git config merge.tool vimdiff
   git config merge.conflictstyle diff3
   git config mergetool.prompt false
   

   This will set vimdiff as the default merge tool.

2. Run the following command in your terminal

   git mergetool
   

3. You will see a vimdiff display in the following format:

     ╔═══════╦══════╦════════╗
     ║       ║      ║        ║
     ║ LOCAL ║ BASE ║ REMOTE ║
     ║       ║      ║        ║
     ╠═══════╩══════╩════════╣
     ║                       ║
     ║        MERGED         ║
     ║                       ║
     ╚═══════════════════════╝
   

   These 4 views are

   • LOCAL: this is the file from the current branch
   • BASE: the common ancestor, how this file looked before both changes
   • REMOTE: the file you are merging into your branch
   • MERGED: the merge result; this is what gets saved in the merge commit and used in the future

   You can navigate among these views using ctrl+w. You can directly reach the MERGED view using ctrl+w followed by j.

   More information about vimdiff navigation is here and here.

4. You can edit the MERGED view like this:

   • If you want to get changes from REMOTE

     :diffg RE
     

   • If you want to get changes from BASE

     :diffg BA
     

   • If you want to get changes from LOCAL

     :diffg LO
     

5. Save, Exit, Commit, and Clean up

   :wqa save and exit from vi

   git commit -m "message"

   git clean Remove extra files (e.g. *.orig) created by the diff tool.

1. Identify which files are in conflict (Git should tell you this).

2. Open each file and examine the diffs; Git demarcates them. Hopefully it will be obvious which version of each block to keep. You may need to discuss it with fellow developers who committed the code.

3. Once you've resolved the conflict in a file git add the_file.

4. Once you've resolved all conflicts, do git rebase --continue or whatever command Git said to do when you completed.

Check out the answers in Stack Overflow question Aborting a merge in Git, especially Charles Bailey's answer which shows how to view the different versions of the file with problems, for example,

# Common base version of the file.
git show :1:some_file.cpp

# 'Ours' version of the file.
git show :2:some_file.cpp

# 'Theirs' version of the file.
git show :3:some_file.cpp

If you're making frequent small commits, then start by looking at the commit comments with git log --merge. Then git diff will show you the conflicts.

For conflicts that involve more than a few lines, it's easier to see what's going on in an external GUI tool. I like opendiff -- Git also supports vimdiff, gvimdiff, kdiff3, tkdiff, meld, xxdiff, emerge out of the box and you can install others: git config merge.tool "your.tool" will set your chosen tool and then git mergetool after a failed merge will show you the diffs in context.

Each time you edit a file to resolve a conflict, git add filename will update the index and your diff will no longer show it. When all the conflicts are handled and their files have been git add-ed, git commit will complete your merge.

I either want my or their version in full, or want to review individual changes and decide for each of them.

Fully accept my or theirs version:

Accept my version (local, ours):

git checkout --ours -- <filename>
git add <filename>              # Marks conflict as resolved
git commit -m "merged bla bla"  # An "empty" commit

Accept their version (remote, theirs):

git checkout --theirs -- <filename>
git add <filename>
git commit -m "merged bla bla"

If you want to do for all conflict files run:

git merge --strategy-option ours

or

git merge --strategy-option theirs

Review all changes and accept them individually

1. git mergetool
2. Review changes and accept either version for each of them.
3. git add <filename>
4. git commit -m "merged bla bla"

Default mergetool works in command line. How to use a command line mergetool should be a separate question.

You can also install visual tool for this, e.g. meld and run

git mergetool -t meld

It will open local version (ours), "base" or "merged" version (the current result of the merge) and remote version (theirs). Save the merged version when you are finished, run git mergetool -t meld again until you get "No files need merging", then go to Steps 3. and 4.

GitLens for Visual Studio Code

You can try GitLens for Visual Studio Code. The key features are:

3. Easily resolve conflicts

I already like this feature:

2. Current Line Blame.

3. Gutter Blame

4. Status Bar Blame

And there are many features. You can check them here.

I understood what a merge conflict was, but when I saw the output of git diff, it looked like nonsense to me at first:

git diff
++<<<<<<< HEAD
 + display full last name boolean in star table
++=======
+ users viewer.id/star.id, and conversation uses user.id
+
++>>>>>>> feat/rspec-tests-for-cancancan

But here is what helped me:

• Everything between <<<<<<< and ======= is what was in one file, and

• Everything between ======= and >>>>>>> is what was in the other file

• So literally all you have to do is open the file with the merge conflicts and remove those lines from either branch (or just make them the same), and the merge will immediately succeed. Problem solved!

This answer is to add an alternative for those Vim users like me that prefers to do everything within the editor.

TL;DR

Tpope came up with this great plugin for Vim called fugitive. Once installed, you can run :Gstatus to check the files that have conflict and :Gdiff to open Git in a three-way merge.

Once in the three-way merge, fugitive will let you get the changes of any of the branches you are merging in the following fashion:

• :diffget //2, get changes from original (HEAD) branch:
• :diffget //3, get changes from merging branch:

Once you are finished merging the file, type :Gwrite in the merged buffer.

Vimcasts released a great video explaining these steps in detail.

I am using Microsoft's Visual Studio Code for resolving conflicts. It's very simple to use. I keep my project open in the workspace. It detects and highlights conflicts. Moreover, it gives GUI options to select whatever change I want to keep from HEAD or incoming.

I follow the below process.

The process to fix a merge conflict:

1. First, pull the latest from the destination branch to which you want to merge git pull origin develop

2. As you get the latest from the destination, now resolve the conflict manually in an IDE by deleting those extra characters.

3. Do a git add to add these edited files to the Git queue so that it can be commit and push to the same branch you are working on.

4. As git add is done, do a git commit to commit the changes.

5. Now push the changes to your working branch by git push origin HEAD

This is it and you will see it resolved in your pull request if you are using Bitbucket or GitHub.

I like using WinMerge (free tool) that does both full entire directory tree comparison/merge and also individual file(s) comparison/merge of the full directory tree compare.

The Git merge conflict is telling you that your pull request will undo/lose/overwrite a coworker's changes, typically because your copy of the content wasn't recent enough.

Steps to resolve can be:

• Take another new clone of the source to a newly named folder,
• Use WinMerge to compare your content and the most recent content to understand the conflict,
• For the file(s) changed by both yourself and your coworker that are causing the Git Merge conflict, look at the lines that your co-worker has added/changed/deleted as per compared to the code lines that you have added/changed/deleted.
• Use the WinMerge left / right code section move arrows to ensure your coworker's work is in your copy of the file and you aren't clobbering their work.

I.e., no magic way to resolve Git merge conflicts other than manually looking at what each person has done to the same source file(s).

That is what I'm thinking.

Note: WinMerge creates .bak files .. and you don't want them copied to source control AzOps, TFS, etc., so if you are sure you have done the edit correctly, remove the .bak files.

Well, all the answers already given seem to explain which tools you can use to detect merge conflicts or how to initiate a merge request...

The answer to your question however is both simple and frustrating. Merge conflicts are almost always to solve by hand manually. If you use a tool like e.g. GitLab, the GUI might help you to find differences in two code versions, but at the end of the day, you have to decide which line should be kept and which should be erased.

A simple example: Programmer A and programmer B both push the same - differently modified - file to a remote repository. Programmer A opens a merge request and GitLab highlights several lines of code where conflicts occur between the two versions. Now it is up to Programmer A and B to decide, who wrote better code in these specific lines. They have to make compromises.

If you simply want to restore the remote master, then

git reset --hard origin/master

WARNING: All local changes will be lost, see https://stackoverflow.com/a/8476004/11769765.