How to resolve merge conflicts in Git repository?

Created 02.10.2008 11:31
Viewed 2.96M times
5006 votes

I want to resolve merge conflicts in my Git repository.

How to do that ?

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 by mwilliams, 02.10.2008 11:40
You can configure a merge tool (kdiff3…) and then use git mergetool. When you're working in large developer teams you'll always encounter merge conflicts. by Grady G Cooper, 18.04.2015 05:37
Don't forget that you can mitigate most merge conflicts by regularly merging downstream! by Ant P, 27.07.2015 09:50
This seems to be a detailed tutorial - by Rajavanya Subramaniyan, 27.12.2015 08:29
This is not specific to this question, but I had to say somewhere that the term "conflict" in the common language for version control systems (VCS) was very badly chosen. What we call conflict in VCS is completely different than what we normally see as a conflict in real life. Say, we have a car accident. One driver says "Oh I did not see you". The other says "Ok, we can fix it". This is not at all a conflict. The conflict can occur after. In VCS, it's the opposite: the simple collision is called a conflict, a modification that consciously undo a known modification cannot even be a conflict. by User, 23.04.2016 20:51
A reaction to my previous comment could be "We know that when there is a git conflict, there is no real conflict," but there is more to it. When programmers work in team there are differences of opinions. It may happen that a programmer consciously undo what another did and that would be closer to a real conflict, but git conflicts have nothing to do with this process. Anyway, I think the term "collision" or "accident" instead of "conflict" would have been closer to what it actually is, because it occurs when both sides did not see the other side coming. by User, 24.04.2016 18:55
how do you ask git which files need merging? by Charlie Parker, 16.07.2016 03:57
@CharlieParker git status will show you quite clearly which files that are in conflict and needs to be merged manually by Spoike, 18.07.2016 08:59
A niche, related question on resolving a conflict in just one file, from command line, using three-way merge with given strategy: by jakub.g, 25.08.2016 08:48
Fascinating question: Asked in 2008, 100% open ended with no hint at all about what it's really about (is it about GUI? about the git commands? about semantics? about pushing/pulling or just general conflicts?) - completely unanswerable. 30 answers, all of them (as far as a quick glance shows) more or less going on about different diff3 and merge tools, none accepted. Top-voted answer mentions a command that does not even work out of the box with a default git installation. Managed to hit the SE start page for me today, 2017, with 1.3m views and thousands of votes both ways. Fascinating. by AnoE, 11.07.2017 16:48 has a nice way of visualizing the issue. Make sure you see this answer. (It has ways to also edit and resolve right from the site, but that's just a convenience.) by Honey, 19.09.2017 15:02
Please select a correct response to this question so that it gets pushed to the top. I only say this because there are now multiple pages of answers. by Blake Frederick, 16.11.2017 17:34 This git mergetool tutorial might help. by Ynjxsjmh, 11.04.2020 07:08
I wrote a short blog post with some hints for new git users, I also speak about solving conflicts, maybe could help someone. by Andrea, 15.12.2020 20:29
Show remaining 10 comments
Answers 38

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 @JoshGlover comment:

The 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 the sample procedure to use vimdiff for 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

  ║       ║      ║        ║
  ║       ║      ║        ║
  ║                       ║
  ║        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 info about vimdiff navigation 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.

02.10.2008 17:50
FYI you can use git mergetool -y to save a few keystrokes if you're merging a lot of files at once. by davr, 17.06.2010 23:32
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. by Josh Glover, 11.05.2011 14:00
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. by Peter Burns, 24.05.2011 05:08
This opened KDiff3. Which I have absolutely no clue how to use. by David Murdoch, 10.06.2011 18:46
You can also use Beyond Compare 3 now (git mergetool -t bc3). by AzP, 30.08.2012 14:59
downloading beyond compare 3 worked great as a windows user didn't take me too long to learn and didn't need to change anything since git is set up to use it from the start. only problem is now i don't know the console command to say the merge conflicts are done. by anon58192932, 05.03.2013 23:36
Although it is probably the fault of the sysadmins at my university, I could not run mergetool because of bcomp.exe not existing. by 2rs2ts, 09.04.2013 14:38
@advocate Just git add the fixed files. Doing so effectively marks them as resolved. by eikonomega, 06.09.2013 17:26
In Windows, Winmerge is a pretty good merge tool. I have been using it for 5 years. by RoboAlex, 24.09.2013 21:49
I'm on Windows and I received this message when running the command git mergetool: This message is displayed because 'merge.tool' is not configured. See 'git mergetool --tool-help' or 'git help config' for more details. 'git mergetool' will now attempt to use one of the following tools: tortoisemerge emerge vimdiff No known merge tool is available. I'll try installing Beyond Compare. by Francisco Zarabozo, 22.02.2014 17:29
Or you can learn how to use vimdiff: It's actually much simpler than it looks. by Ruslan Osipov, 30.05.2014 19:15
IMO This answer could be improved by adding detail about setting the tools, and if you describe what happens if you start using the wrong gui and need to switch (does that ruin the merge?) by geneorama, 29.03.2016 17:27
Using FileMerge app on Mac, I figured out if you select a diff'd item, you can use the left/right arrow keys to select which one of the two to use by Gene Bo, 16.05.2016 18:59
Should I use meld to resolve conflicts? by hellboy, 14.11.2016 09:12
I highly recommend using the 'meld' tool. It's a cross platform diff tool that makes it easier to merge than using vim. If you are a Vim user then there is the fugitive.vim plugin… by icc97, 27.06.2017 04:45
This is amazing, thanks so much. I had no idea I even had this installed. For me, meld opened by default, which is identical to the PyCharm confilct manager I used to use. by Anonymous, 06.02.2018 20:51
On windows with VsCode? by Legends, 10.06.2018 11:13
For Step 4, if you want to take all the changes instead of just the current buffer from remote/local/base, you can use %diffg instead (% is a range specification,[range]), e.g. :%diffg BA or :%diffg LO or :%diffg RE by Balraj Bains, 02.08.2018 06:58
This is super obvious in retrospect, but it tripped me so I will add -- you need to put your cursor over each individual merge conflict to use diffg. It will not automatically take the whole file. by Ashish, 14.05.2019 20:15
E93: More than one match for RE I guess I'll just install Beyond Compare 3 first and then try again. by Someone Somewhere, 11.07.2019 22:14
"This will set vimdiff as the default merge tool." Git is ignoring my tool choice and just uses the default one that asks for "Use (c)reated or (d)eleted file, or (a)bort?" by Unknow0059, 10.01.2021 17:25
Show remaining 16 comments

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 my, oh my, upstream changed some things, but just to use my 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.


04.08.2010 17:04
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" by petrocket, 08.06.2011 17:39
This was indeed what I was looking for! Why, oh why, can't "git checkout -- filename.c" work here, too.. Would be too consistent, I guess. by Zds, 27.03.2012 08:23
Careful! The meaning of --ours and --theirs is reversed. --ours == the remote. --theirs == local. See git merge --help by mmell, 04.03.2013 22:56
If you need to do it to many files: git checkout --theirs *.java by Jorge Nunez Newton, 13.03.2013 18:37
Thanks so much. I need to confirm that: --theirs == server, remote. --ours == local by Thanh, 08.05.2013 03:51
In my case, I confirm that --theirs = remote repository, --ours = my own local repository. It is the opposite of @mmell comments. by Aryo, 22.06.2013 12:59
If you git stash pop and run in to a conflict, --ours will be HEAD and --theirs will be the stashed changes. by Matt Briançon, 16.10.2013 21:37
@mmell Only on a rebase, apparently. See this question by Navin, 10.11.2013 06:19
should we do 'git commit -m "using theirs"'? Last time I only "add" resolved file and it was enough to continue merge operation. by Yura, 08.04.2014 13:45
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. by User, 26.05.2014 04:27
If instead of brutally doing git checkout --ours file.txt you want to perform an automatic three-way-merge on that file using --ours strategy, you can use git merge-file for that, see by jakub.g, 25.08.2016 08:52
Why would you fetch before a pull? Doesn't it always fetch when you pull automatically? by TankorSmash, 25.08.2016 20:25
@Script47 Your edit changed an acceptable idiom and nothing else. If I were reviewing it, I'd reject your edit. by Michael, 11.06.2019 15:23
@Michael I wasn't aware, it looked like a spelling mistake. by Script47, 11.06.2019 16:39
I dont feel ta da at all, it so hard. And also scary by Aadam, 02.04.2020 12:52
Show remaining 10 comments

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.

28.09.2011 21:08
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). by alxndr, 01.05.2014 22:15
After a rebase attempt which resulted in a merge conflict: $ git log --merge -p build.xml output: fatal: --merge without MERGE_HEAD? by Ed Randall, 17.06.2016 09:15
what if I have changes on one file from branch1 and deletion of that file in branch2. How can I solve that merge conflict? Is there any way using git where I can merge them by keeping the changes of one branch? by Honey, 21.01.2017 14:48
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. by ffxsam, 04.04.2017 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. by Dave Abrahams, 02.07.2017 03:31
Big +1 for recommending diff3. The default conflict style makes some conflicts literally impossible to resolve. For more information see… by Tom Ellis, 24.09.2020 11:14
Show remaining 1 comments
  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.

02.10.2008 12:41
@Justin Think of Git as tracking content rather than tracking files. Then it's easy to see that the content you've updated isn't in the repository and needs to be added. This way of thinking also explains why Git doesn't track empty folders: Although they are technically files, there isn't any content to track. by Gareth, 12.10.2010 09:17
content is there, conflict occurs because there 2 version of content. Therefore "git add" does not sound correct. And it does not work (git add, git commit) if you want commit only that one file after conflict was resolved ("fatal: cannot do a partial commit during a merge.") by Dainius, 14.09.2011 09:19
Yes, technically, this answers the question which as asked, but is not a usable answer, in my opinion, sorry. What's the point of making one branch the same as another? Of course a merge will have conflicts.. by Thufir, 09.08.2012 05:56
Thulfir: who said anything about making one branch the same as another? There are different scenarios where you need to merge, without "making one branch the same as another". One is when you're done with a development branch and want to incorporate its changes into the master branch; after this, the development branch can be deleted. Another one is when you want to rebase your development branch, in order to ease the eventual final merge into the master. by Teemu Leisti, 21.09.2012 08:50
@JustinGrant git add stages files in the index; it does not add anything to the repository. git commit adds things to the repository. This usage makes sense for merges -- the merge automatically stages all of the changes that can be merged automatically; it is your responsibility to merge the rest of the changes and add those to the index when you are done. by Mark E. Haase, 17.10.2012 15:13
how do you ask git which files need merging? by Charlie Parker, 16.07.2016 03:57
Step 2 amuses me. It sounds so easy. Then one day you have a merge conflict that impacts thousands of files written by people that no longer work for the company. Sigh... by Brian Knoblauch, 02.08.2016 17:08
Show remaining 2 comments

Merge conflicts happens when changes are made to a file at the same time. Here is how to solve it.

git CLI

Here are simple steps what to do when you get into conflicted state:

  1. Note the list of conflicted files with: git status (under Unmerged paths section).
  2. Solve the conflicts separately for each file by one of the following approaches:

    • Use GUI to solve the conflicts: git mergetool (the easiest way).

    • To accept remote/other version, use: git checkout --theirs path/file. This will reject any local changes you did for that file.

    • To accept local/our version, use: git checkout --ours path/file

      However you've to be careful, as remote changes that conflicts were done for some reason.

      Related: What is the precise meaning of "ours" and "theirs" in git?

    • Edit the conflicted files manually and look for the code block between <<<<</>>>>> then choose the version either from above or below =====. See: How conflicts are presented.

    • Path and filename conflicts can be solved by git add/git rm.

  3. Finally, review the files ready for commit using: git status.

    If you still have any files under Unmerged paths, and you did solve the conflict manually, then let Git know that you solved it by: git add path/file.

  4. If all conflicts were solved successfully, commit the changes by: git commit -a and push to remote as usual.

See also: Resolving a merge conflict from the command line at GitHub

For practical tutorial, check: Scenario 5 - Fixing Merge Conflicts by Katacoda.


I've successfully used DiffMerge which can visually compare and merge files on Windows, macOS and Linux/Unix.

It graphically can show the changes between 3 files and it allows automatic merging (when safe to do so) and full control over editing the resulting file.


Image source: DiffMerge (Linux screenshot)

Simply download it and run in repo as:

git mergetool -t diffmerge .


On macOS you can install via:

brew install caskroom/cask/brew-cask
brew cask install diffmerge

And probably (if not provided) you need the following extra simple wrapper placed in your PATH (e.g. /usr/bin):

exec ${DIFFMERGE_EXE} --nosplash "$@"

Then you can use the following keyboard shortcuts:

  • -Alt-Up/Down to jump to previous/next changes.
  • -Alt-Left/Right to accept change from left or right

Alternatively you can use opendiff (part of Xcode Tools) which lets you merge two files or directories together to create a third file or directory.

05.08.2015 14:29

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
03.10.2008 15:15
Also check out the "-m" option to "git checkout -m" - it allows you to extract the different flies back out into your workspace by qneill, 05.02.2015 22:06
This saved me. Looking at each file separately allowed me to remember what I was going for in each branch. Then I could make the decision to choose. by Rohmer, 14.05.2016 21:59

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.

02.10.2008 16:11
Using "git add" is the real trick here. You may not even want to commit (maybe you want to stash), but you have to do "git add" to complete the merge. I think mergetool does the add for you (although it isn't in the manpage), but if you do the merge manually, you need to use "git add" to complete it (even if you don't want to commit). by Brent Bradburn, 25.10.2010 09:37

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


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.

29.09.2016 13:02
This command: git checkout --theirs -- <filename> changed ALL the files to theirs, not just <filename> by Donato, 26.06.2018 01:00
Actually I was wrong. This only updates specified file. by Donato, 26.06.2018 01:23

See How Conflicts Are Presented or, in Git, the git merge documentation 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.

14.07.2013 18:34

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 files 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 three 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 the 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.

22.02.2013 23:04


In speaking of pull/fetch/merge in the above answers, I would like to share an interesting and productive trick,

git pull --rebase

This above command is the most useful command in my git life which saved a lots of time.

Before pushing your newly committed change to remote server, try git pull --rebase rather git pull and manual merge and it will automatically sync latest remote server changes (with a fetch + merge) and will put your local latest commit at the top in git log. No need to worry about manual pull/merge.

In case of conflict, just use

git mergetool
git add conflict_file
git rebase --continue

Find details at:

25.12.2015 15:24

Simply, if you know well that changes in one of the repositories is not important, and want to resolve all changes in favor of the other one, use:

git checkout . --ours

to resolve changes in the favor of your repository, or

git checkout . --theirs

to resolve changes in favor of the other or the main repository.

Or else you will have to use a GUI merge tool to step through files one by one, say the merge tool is p4merge, or write any one's name you've already installed

git mergetool -t p4merge

and after finishing a file, you will have to save and close, so the next one will open.

26.01.2016 17:42
git checkout . --theirs resolved my problem thanks by Ramesh Chand, 10.03.2016 06:53
if you prefer to resolve conflicts manually try opening the folder in Visual Studio Code, it marks files with conflicts and colors conflict lines inside every one by Mohamed Selim, 03.07.2016 08:31

Please follow the following steps to fix merge conflicts in Git:

  1. Check the Git status: git status

  2. Get the patchset: git fetch (checkout the right patch from your Git commit)

  3. Checkout a local branch (temp1 in my example here): git checkout -b temp1

  4. Pull the recent contents from master: git pull --rebase origin master

  5. Start the mergetool and check the conflicts and fix them...and check the changes in the remote branch with your current branch: git mergetool

  6. Check the status again: git status

  7. Delete the unwanted files locally created by mergetool, usually mergetool creates extra file with *.orig extension. Please delete that file as that is just the duplicate and fix changes locally and add the correct version of your files. git add #your_changed_correct_files

  8. Check the status again: git status

  9. Commit the changes to the same commit id (this avoids a new separate patch set): git commit --amend

  10. Push to the master branch: git push (to your Git repository)

16.04.2015 07:02

There are 3 steps:

  1. Find which files cause conflicts by command

    git status
  2. Check the files, in which you would find the conflicts marked like

  3. Change it to the way you want it, then commit with commands

    git add solved_conflicts_files
    git commit -m 'merge msg'
23.06.2017 14:38
Worked for me! Thanks! by Nuwan Jayawardene, 18.09.2017 04:00
You must pay attention if do this during rebase. You should use git rebase --continue instead of git commit by Samuel Dauzon, 29.10.2018 13:37

CoolAJ86's answer sums up pretty much everything. In case you have changes in both branches in the same piece of code you will have to do a manual merge. Open the file in conflict in any text editor and you should see following structure.

(Code not in Conflict)
(first alternative for conflict starts here)
Multiple code lines here
(second alternative for conflict starts here)
Multiple code lines here too    
(Code not in conflict here)

Choose one of the alternatives or a combination of both in a way that you want new code to be, while removing equal signs and angle brackets.

git commit -a -m "commit message"
git push origin master
25.01.2014 16:17

You could fix merge conflicts in a number of ways as other have detailed.

I think the real key is knowing how changes flow with local and remote repositories. The key to this is understanding tracking branches. I have found that I think of the tracking branch as the 'missing piece in the middle' between me my local, actual 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 -

a) All new/changed files get added and that might include some unwanted changes.
b) You don't get to review the file list first.

So 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 rather than the -m option.

[Update - as time has passed I've switched more to:

git status # Make sure I know whats going on
git add .
git commit # Then use the 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 merged code and/or merge conflicts for code that shouldn't have been merged.

Instead I try to do

git checkout master
git fetch   
git rebase --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?

19.04.2013 01:08
Hey, I kinda understood your answer. But since i'm new to github merge conflicts, I think there is something missing. What happens to your local modifications when you do git checkout master and git fetch and git rebase --hard origin/master by Suhaib, 08.08.2017 17:43
I believe you should add more details on what to do. Another example which is confusing me, you mentioned in your answer: we do git add ., will it save our local modifications so we can follow up with git checkout master ? or are they two different scenarios ? by Suhaib, 08.08.2017 17:47
@MichaelDurrant $ git rebase --hard origin/master b5a30cc159ba8dd error: unknown optionhard' usage: git rebase [-i] [options] [--exec <cmd>] [--onto <newbase>] [<upstream>] [<branch>] or: git rebase [-i] [options] [--exec <cmd>] [--onto <newbase>] --root [<branch>] or: git rebase --continue | --abort | --skip | --edit-todo ` by likejudo, 23.05.2020 20:23

If you want to merge from branch test to master, you can follow these steps:

Step 1: Go to the branch

git checkout test

Step 2:

git pull --rebase origin master

Step 3: If there are some conflicts, go to these files to modify it.

Step 4: Add these changes

git add #your_changes_files

Step 5:

git rebase --continue

Step 6: If there is still conflict, go back to step 3 again. If there is no conflict, do following:

git push origin +test

Step 7: And then there is no conflict between test and master. You can use merge directly.

18.08.2014 19:42

As of December 12th 2016, you can merge branches and resolve conflicts on

Thus, if you don't want to use the command-line or any 3rd party tools that are offered here from older answers, go with GitHub's native tool.

This blog post explains in detail, but the basics are that upon 'merging' two branches via the UI, you will now see a 'resolve conflicts' option that will take you to an editor allowing you to deal with these merge conflicts.

enter image description here

09.01.2017 19:45
this is not asking about github thus I down voted what I view to be a very poor answer. by mschuett, 25.01.2017 05:06
@mschuett is right, the question is "how to resolve conflicts in git", not "how to resolve conflicts in github". There is a difference and there is already far too many people that think git and github are the same thing, so anything that propagate that feeling is wrong. by Patrick Mevzek, 05.04.2018 16:21
git log --merge -p [[--] path]

Does not seem to always work for me and usually ends up displaying every commit that was different between the two branches, this happens even when using -- to separate the path from the command.

What I do to work around this issue is open up two command lines and in one run

git log ..$MERGED_IN_BRANCH --pretty=full -p [path]

and in the other

git log $MERGED_IN_BRANCH.. --pretty=full -p [path]

Replacing $MERGED_IN_BRANCH with the branch I merged in and [path] with the file that is conflicting. This command will log all the commits, in patch form, between (..) two commits. If you leave one side empty like in the commands above git will automatically use HEAD (the branch you are merging into in this case).

This will allow you to see what commits went into the file in the two branches after they diverged. It usually makes it much easier to solve conflicts.

11.12.2014 15:19

Using patience

For a big merge conflict, using patience provided good results for me. It will try to match blocks rather than individual lines.

If you change the indentation of your program for instance, the default Git merge strategy sometimes matches single braces { which belongs to different functions. This is avoided with patience:

git merge -s recursive -X patience other-branch

From the documentation:

With this option, merge-recursive spends a little extra time to avoid 
mismerges that sometimes occur due to unimportant matching lines 
(e.g., braces from distinct functions). Use this when the branches to 
be merged have diverged wildly.

Comparison with the common ancestor

If you have a merge conflict and want to see what others had in mind when modifying their branch, it's sometimes easier to compare their branch directly with the common ancestor (instead of our branch). For that you can use merge-base:

git diff $(git merge-base <our-branch> <their-branch>) <their-branch>

Usually, you only want to see the changes for a particular file:

git diff $(git merge-base <our-branch> <their-branch>) <their-branch> <file>
30.11.2016 19:51
In my case this didn't resolve merge conflicts well, since for some reason it kept duplicate lines of config in C# projects. Though it was more friendly than ENTIRE FILE IS DIFFERENT, which I had before by Mathijs Segers, 08.09.2017 07:55

I always follow the below steps to avoid conflicts.

  • git checkout master (Come to the master branch)
  • git pull (Update your master to get the latest code)
  • git checkout -b mybranch (Checkout a new a branch and start working on that branch so that your master always remains top of trunk.)
  • git add . AND git commit AND git push (on your local branch after your changes)
  • git checkout master (Come back to your master.)

Now you can do the same and maintain as many local branches you want and work simultaneous my just doing a git checkout to your branch when ever necessary.

12.02.2015 04:25

Merge conflicts could occur in different situations:

  • When running git fetch and then git merge
  • When running git fetch and then git rebase
  • When running git pull (which is actually equal to one of the above-mentioned conditions)
  • When running git stash pop
  • When you're applying git patches (commits that are exported to files to be transferred, for example, by email)

You need to install a merge tool which is compatible with Git to resolve the conflicts. I personally use KDiff3, and I've found it nice and handy. You can download its Windows version here:

BTW if you install Git Extensions there is an option in its setup wizard to install Kdiff3.

Then setup git configs to use Kdiff as its mergetool:

$ git config --global --add merge.tool kdiff3
$ git config --global --add mergetool.kdiff3.path "C:/Program Files/KDiff3/kdiff3.exe"
$ git config --global --add mergetool.kdiff3.trustExitCode false

$ git config --global --add diff.guitool kdiff3
$ git config --global --add difftool.kdiff3.path "C:/Program Files/KDiff3/kdiff3.exe"
$ git config --global --add difftool.kdiff3.trustExitCode false

(Remember to replace the path with the actual path of Kdiff exe file.)

Then every time you come across a merge conflict you just need to run this command:

$ git mergetool

Then it opens the Kdiff3, and first tries to resolve the merge conflicts automatically. Most of the conflicts would be resolved spontaneously and you need to fix the rest manually.

Here's what Kdiff3 looks like:

Enter image description here

Then once you're done, save the file and it goes to the next file with conflict and you do the same thing again until all the conflicts are resolved.

To check if everything is merged successfully, just run the mergetool command again, you should get this result:

$ git mergetool
No files need merging
18.06.2016 05:29

Gitlense For VS Code

You can try Gitlense for VS Code, They key features are:

3. Easily Resolve Conflicts.

I already like this feature:

enter image description here

2. Current Line Blame.

enter image description here

3. Gutter Blame

enter image description here

4. Status Bar Blame

enter image description here

And there are many features you can check them here.

05.01.2019 18:33
One of the best tools I have ever used, and I'm still using it for all my projects! by DrumM, 06.01.2021 11:05

This answers is to add an alternative for those VIM users like I that prefers to do everything within the editor.


enter image description here

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 3 ways merge.

Once in the 3-ways 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 in detail this steps.

16.10.2017 06:01
git fetch <br>
git checkout **your branch**<br>
git rebase master<br>

In this step you will try to fix the conflict using your preferred IDE.

You can follow this link to check how to fix the conflict in the file

git add<br>
git rebase --continue<br>
git commit --amend<br>
git push origin HEAD:refs/drafts/master  (push like a drafts)<br>

Now everything is fine and you will find your commit in gerrit

I hope that this will help everyone concerning this issue.

05.07.2017 13:25

A safer way to resolve conflicts is to use git-mediate (the common solutions suggested here are quite error prone imho).

See this post for a quick intro on how to use it.

29.12.2016 16:46

If you do not use a tool to merge, first copy your code outside:

- `checkout master`
- `git pull` / get new commit
- `git checkout` to your branch
- `git rebase master`

It resolve conflict and you can copy your code.

10.06.2014 08:11
Does that sequence always help? Please explain what and how it does and how that code answers the question. by Oleg Estekhin, 10.06.2014 08:32

For those who are using Visual Studio (2015 in my case)

  1. Close your project in VS. Especially in big projects VS tends to freak out when merging using the UI.

  2. Do the merge in command prompt.

    git checkout target_branch

    git merge source_branch

  3. Then open the project in VS and go to Team Explorer -> Branch. Now there is a message that says Merge is pending and conflicting files are listed right below the message.

  4. Click the conflicting file and you will have the option to Merge, Compare, Take Source, Take Target. The merge tool in VS is very easy to use.

10.07.2017 20:29
I'm using VS Code 2017 on a very large project and do not have a need to close the project. It handles it quite well :) by protoEvangelion, 10.08.2017 16:22

If you are using intelliJ as IDE Try to merge parent to your branch by

git checkout <localbranch>
git merge origin/<remotebranch>

It will show all conflicts like this

A_MBPro:test anu$ git merge origin/ Auto-merging src/test/java/com/.../ CONFLICT (content): Merge conflict in src/test/java/com/.../

Now note that the file is shown in red in intelliJ Also git status will show

Unmerged paths:
(use "git add <file>..." to mark resolution)
both modified:   src/test/java/com/.../

Open the file in intelliJ, it will have sections with

  <<<<<<< HEAD
    public void testMethod() {
    public void testMethod() { ...
    >>>>>>> origin/<remotebranch>

where HEAD is changes on your local branch and origin/ is changes from the remote branch. Here keep the stuff that you need and remove the stuff you don't need.After that the normal steps should do. That is

   git add
   git commit -m "commit message"
   git push
11.07.2017 16:23

I am using Microsoft's Visual Code for resolving conflicts. Its very simple to use. I keep my project open in the workspace. It detects and highlights conflicts, moreover give GUI options to select whatever change I want to keep from HEAD or incoming.enter image description here

02.10.2019 06:53

Try Visual Studio Code for editing if you aren't already. What it does is after you try merging(and land up in merge conflicts).VS code automatically detects the merge conflicts.

It can help you very well by showing what are the changes made to the original one and should you accept incoming or

current change(meaning original one before merging)'?.

It helped for me and it can work for you too !

PS: It will work only if you've configured git with with your code and Visual Studio Code.

16.03.2018 06:26

I follow the below process.

The process to fix 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 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.

13.10.2017 21:49
git checkout branch1

git fetch origin

git rebase -p origin/mainbranch

If there are merge conflicts, fix them. Then, continue the rebase process by running: git rebase –-continue

after the fixing you can commit and push your local branch to remote branch

git push origin branch1
08.08.2017 08:41

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

git diff
++<<<<<<< HEAD 
 + display full last name boolean in star table 
+ users, and conversation uses
++>>>>>>> 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 remove those lines from either branch (or just make them the same), and the merge will immediately succeed. Problem solved!

09.02.2021 11:24

If you simply want to restore the remote master, then

git reset --hard origin/master

WARNING: All local changes will be lost, see

05.06.2020 16:51
This is NOT what resolving merge conflicts mean! by Pedro Lamarão, 29.09.2020 17:51
But it overcomes the error message. Beginners may just want to undo their changes to "resolve merge conflicts". The warning is bold. Advanced users can fiddle with committing, pushing, fetching, adding, editing, merging, creating branches. by Friedrich, 30.09.2020 08:23

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.

No one had mentioned WinMerge in this trail thus far, thus am mentioning here.

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

Steps to resolve can be:

  • Take another new clone of 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 co-worker 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 co-workers 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.

23.07.2020 07:13

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

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.

09.08.2020 12:11

This is now really easy with Atom. I just open the file in Atom, it shows the conflicting lines, and lets you pick the one you want to use with a click of the mouse, and resolves the conflict.

Add/commit/push and all is well.

28.02.2021 03:29