How do I fix merge conflicts in Git?
Is there a good way to explain how to resolve merge conflicts in Git?
improve this question | comment
Krystina Shields Created at: 2013-11-13 17:07:41 UTC By Krystina Shields
The following blog post seems to give a very good example on how to handle merge conflict with Git that should get you going in the right direction. Handling and Avoiding Conflicts in Git - Daron Dibbert
9 Answers
You could fix merge conflicts in a number of ways as other have detailed.

I think the real key is understanding how changes flow with local and remote repositories.  The key to this is understading tracking branches.  I have found that I think of the tracking branch as the 'missing piece in the middle' between me my local, atual files directory and the remote defined as origin.  

I've personally got into the habit of 2 things to help avoid this.

Instead of:

git add .
git commit -m"some msg"

Which has two drawbacks - 1) All files get added and that might include some not needed and 2) You don't get to review the file list first, instead I do:

git add file,file2,file3...
git commit # Then type the files in the editor and save-quit.

This way you are more deliberate about which files get added and you also get to review the list and think a bit more while using the editor for the message.  I find it also improves my commit messages when I use a full screen editor.

Also (and more relevant to your situation), I try to avoid:

git pull


git pull origin master.

because pull implies a merge and if you have changes locally that you didn't want merged you can easily end up with merge conflicts that you then have to spend time resolving.

Instead I try to do

git checkout master
git fetch   
git reset --hard origin/master # or whatever branch I want.

You may also find this helpful:

git branch, fork, fetch, merge, rebase and clone, what are the differences?
Identify which files are in conflict (Git should tell you this)
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
Once you've resolved the conflict in a file git add the_file
Once you've resolved all conflicts, do git rebase --continue or whatever command git said to do when you completed
Here's a probable use-case, from the top:

You're going to pull some changes, but oops, you're not up to date:

> git fetch origin
> git pull origin master
From ssh://
 * branch            master     -> FETCH_HEAD
Updating a030c3a..ee25213
error: Entry 'filename.c' not uptodate. Cannot merge.

So you get up-to-date and try again, but have a conflict:

> git add filename.c
> git commit -m "made some wild and crazy changes"
> git pull origin master
From ssh://
 * branch            master     -> FETCH_HEAD
Auto-merging filename.c
CONFLICT (content): Merge conflict in filename.c
Automatic merge failed; fix conflicts and then commit the result.

So you decide to take a look at the changes:

> git mergetool

Oh me, oh my, upstream changed some things, but just to use my changes.... no... their changes...

> git checkout --ours filename.c
> git checkout --theirs filename.c
> git add filename.c
> git commit -m "using theirs"

And then we try a final time

> git pull origin master
From ssh://
 * branch            master     -> FETCH_HEAD
Already up-to-date.

I find merge tools rarely help me understand the conflict or the resolution. I'm usually more successful looking at the conflict markers in a text editor and using git log as a supplement.

Here are a few tips:

Tip One

The best thing I have found is to use the "diff3" merge conflict style:

git config merge.conflictstyle diff3

This produces conflict markers like this:

Changes made on the branch that is being merged into. In most cases,
this is the branch that I have currently checked out (i.e. HEAD).
The common ancestor version.
Changes made on the branch that is being merged in. This is often a 
feature/topic branch.

The middle section is what the common ancestor looked like. This is useful because you can compare it to the top and bottom versions to get a better sense of what was changed on each branch, which gives you a better idea for what the purpose of each change was.

If the conflict is only a few lines, this generally makes the conflict very obvious. (Knowing how to fix a conflict is very different; you need to be aware of what other people are working on. If you're confused, it's probably best to just call that person into your room so they can see what you're looking at.)

If the conflict is longer, then I will cut and paste each of the three sections into three separate files, such as "mine", "common" and "theirs".

Then I can run the following commands to see the two diff hunks that caused the conflict:

diff common mine
diff common theirs

This is not the same as using merge tool, since merge tool will include all of the non-conflicting diff hunks too. I find that to be distracting.

Tip Two

Somebody already mentioned this, but understanding the intention behind each diff hunk is generally very helpful for understanding where a conflict came from and how to handle it.

git log --merge -p <name of file>

This shows all of the commits that touched that file in between the common ancestor and the two heads you are merging. (So it doesn't include commits that already exist in both branches before merging.) This helps you ignore diff hunks that clearly are not a factor in your current conflict.

Tip Three

Verify your changes with automated tools.

If you have automated tests, run those. If you have a lint, run that. If it's a buildable project, then build it before you commit, etc. In all cases, you need to do a bit of testing to make sure your changes didn't break anything. (Heck, even a merge without conflicts can break working code.)

Tip Four

Plan ahead; communicate with co-workers.

Planning ahead and being aware of what others are working on can help prevent merge conflicts and/or help resolve them earlier -- while the details are still fresh in mind. 

For example, if you know that you and another person are both working on different refactoring that will both affect the same set of files, you should talk to each other ahead of time and get a better sense for what types of changes each of you is making. You might save considerable time and effort if you conduct your planned serially rather than in parallel. 

For major refactorings that cut across a large swath of code, you should strongly consider working serially: everybody stops working on that area of the code while 1 person performs the complete refactoring.

If you can't work serially (due to time pressure, maybe), then communicating about expected merge conflicts at least helps you solve the problems sooner while the details are still fresh in mind. For example, if a co-worker is making a disruptive series of commits over the course of a 1-week period, you may choose to merge/rebase on that co-workers branch once or twice each day during that week. That way, if you do find merge/rebase conflicts, you can solve them more quickly than if you wait a few weeks to merge everything together in one big lump.

Tip Five

If you're unsure of a merge, don't force it.

Merging can feel overwhelming, especially when there are a lot of conflicting files and the conflict markers cover hundreds of lines. Often times when estimating software projects we don't include enough time for overhead items like handling a gnarly merge, so it feels like a real drag to spend several hours dissecting each conflict.

In the long run, planning ahead and being aware of what others are working on are the best tools for anticipating merge conflicts and prepare yourself to resolve them correctly in less time.
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.  Much better than doing the whole thing by hand certainly.
Checkout the answers in 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.
See How Conflicts Are Presented in Git the git merge docs to understand what merge conflict markers are.

Also, the How to Resolve Conflicts section explains how to resolve the conflicts:

  After seeing a conflict, you can do two things:
  Decide not to merge. The only clean-ups you need are to reset the index file to the HEAD commit to reverse 2. and to clean up working tree changes made by 2. and 3.; git merge --abort can be used for this.
  Resolve the conflicts. Git will mark the conflicts in the working tree. Edit the files into shape and git add them to the index. Use git commit to seal the deal.
  You can work through the conflict with a number of tools:
  Use a mergetool. git mergetool to launch a graphical mergetool which will work you through the merge.
  Look at the diffs. git diff will show a three-way diff, highlighting changes from both the HEAD and MERGE_HEAD versions.
  Look at the diffs from each branch. git log --merge -p <path> will show diffs first for the HEAD version and then the MERGE_HEAD version.
  Look at the originals. git show :1:filename shows the common ancestor, git show :2:filename shows the HEAD version, and git show :3:filename shows the MERGE_HEAD version.

You can also read about merge conflict markers and how to resolve them in the Pro Git book section Basic Merge Conflicts.
For Emacs users which want to resolve merge conflicts semi-manually:

git diff --name-status --diff-filter=U

shows all files which require conflict resolution.
Open each of those file one by one, or all at once by:

emacs $(git diff --name-only --diff-filter=U)

When visiting a buffer requiring edits in emacs type

ALT+x vc-resolve-conflicts

This will open 3 buffers (mine, theirs, and the output buffer). Navigate by pressing 'n' (next region), 'p' (prevision region). Press 'a' and 'b' to copy mine or theirs region to output buffer, respectively. And/or edit the output buffer directly.
When finished: Press 'q', emacs asks you if you want to save this buffer: yes.
After finishing a buffer mark it as resolved by running from the teriminal:

git add FILENAME

When finished with all buffers type

git commit

to finish the merge.
Your Answer