Categories
git git-merge git-merge-conflict merge-conflict-resolution

How do I resolve merge conflicts in a Git repository?

5222

How do I resolve merge conflicts in my Git repository?

10

3276

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.

Step 1: Run 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.

Step 2: Run following command in terminal

git mergetool

Step 3: You will see a vimdiff display in following format

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

These 4 views are

LOCAL – this is file from the current branch

BASE – common ancestor, how file looked before both changes

REMOTE – file you are merging into your branch

MERGED – merge result, this is what gets saved in the repo

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

More information about vimdiff navigation is here and here.

Step 4. You could edit the MERGED view the following way

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

Step 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 diff tool.

20

  • 57

    FYI you can use git mergetool -y to save a few keystrokes if you’re merging a lot of files at once.

    – davr

    Jun 17, 2010 at 23:32

  • 386

    Well, it 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.

    May 11, 2011 at 14:00

  • 31

    Good point Josh. On ubuntu I’ve had the best luck with meld, its three way merge display isn’t bad. On OSX git chose a nice default.

    May 24, 2011 at 5:08

  • 18

    This opened KDiff3. Which I have absolutely no clue how to use.

    Jun 10, 2011 at 18:46

  • 8

    You can also use Beyond Compare 3 now (git mergetool -t bc3).

    – AzP

    Aug 30, 2012 at 14:59


1773

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://[email protected]:22/projectname
 * 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://[email protected]:22/projectname
 * 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 my, 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://[email protected]:22/projectname
 * branch            master     -> FETCH_HEAD
Already up-to-date.

Ta-da!

14

  • 21

    This was super helpful because I had a lot of merge errors with binary files (art assets) and merging those seems to always fail, so I need to overwrite it with the new file always and not “merge”

    – petrocket

    Jun 8, 2011 at 17:39

  • 199

    Careful! The meaning of –ours and –theirs is reversed. –ours == the remote. –theirs == local. See git merge --help

    – mmell

    Mar 4, 2013 at 22:56


  • 61

    In my case, I confirm that –theirs = remote repository, –ours = my own local repository. It is the opposite of @mmell comments.

    – Aryo

    Jun 22, 2013 at 12:59

  • 26

    @mmell Only on a rebase, apparently. See this question

    – Navin

    Nov 10, 2013 at 6:19


  • 207

    Guys, “ours” and “theirs” is relative to whether or not you are merging or rebasing. If you’re merging, then “ours” means the branch you’re merging into, and “theirs” is the branch you’re merging in. When you’re rebasing, then “ours” means the commits you’re rebasing onto, while “theirs” refers to the commits that you want to rebase.

    – user456814

    May 26, 2014 at 4:27

773

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 a merge tool, since a 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 changes 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 one 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 one-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.

5

  • 8

    The diff3 option is a great feature to have with merges. The only GUI I’ve come across that shows it is Perforce’s p4merge, which can be installed and used separately from Perforce’s other tools (which I’ve not used, but heard complaints about).

    – alxndr

    May 1, 2014 at 22:15

  • 4

    After a rebase attempt which resulted in a merge conflict: $ git log –merge -p build.xml output: fatal: –merge without MERGE_HEAD?

    Jun 17, 2016 at 9:15


  • git config merge.conflictstyle diff3 – thank you, sir. This is amazing and has freed me from trying to find (and pay $$) for a good 3 way merge GUI. IMO this is better because it shows the common ancestor as well as local/remote, and shows the last commit log lines which (AFAIK) no GUI does. The commits definitely help you identify what code belongs to what branch.

    – ffxsam

    Apr 4, 2017 at 16:00

  • I have found that sometimes the diff3 conflictstyle results in enormous diff hunks that are largely identical, whereas the default will produce smaller, more manageable, hunks. Unfortunately, I don’t have a reproducer I can use for a bug report. But if you encounter this problem you might consider turning off the option temporarily.

    Jul 2, 2017 at 3:31

  • Big +1 for recommending diff3. The default conflict style makes some conflicts literally impossible to resolve. For more information see stackoverflow.com/questions/27417656/…

    – Tom Ellis

    Sep 24, 2020 at 11:14