You can configure a merge tool (kdiff3 jebaird.com/2013/07/08/…) and then use git mergetool. When you're working in large developer teams you'll always encounter merge conflicts.
– Grady G CooperApr 18 '15 at 5:37

Don't forget that you can mitigate most merge conflicts by regularly merging downstream!
– Ant PJul 27 '15 at 9:50

34 Answers
34

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

FYI you can use git mergetool -y to save a few keystrokes if you're merging a lot of files at once.
– davrJun 17 '10 at 23:32

356

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.
– Josh GloverMay 11 '11 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.
– Peter BurnsMay 24 '11 at 5:08

18

This opened KDiff3. Which I have absolutely no clue how to use.
– David MurdochJun 10 '11 at 18:46

5

You can also use Beyond Compare 3 now (git mergetool -t bc3).
– AzPAug 30 '12 at 14:59

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"
– petrocketJun 8 '11 at 17:39

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.
– user456814May 26 '14 at 4:27

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.

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).
– alxndrMay 1 '14 at 22: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?
– HoneyJan 21 '17 at 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.
– ffxsamApr 4 '17 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.
– Dave AbrahamsJul 2 '17 at 3:31

@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.
– GarethOct 12 '10 at 9:17

6

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.")
– DainiusSep 14 '11 at 9:19

1

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..
– ThufirAug 9 '12 at 5:56

3

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.
– Teemu LeistiSep 21 '12 at 8:50

3

@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.
– Mark E. HaaseOct 17 '12 at 15:13

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.

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).
– nobarOct 25 '10 at 9:37

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.

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.

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

Check the status again:
git status

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

Check the status again:
git status

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

Bonus:

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.

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

or

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.

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
– SuhaibAug 8 '17 at 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 ?
– SuhaibAug 8 '17 at 17:47

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.

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.

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

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.

@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.
– Patrick MevzekApr 5 '18 at 16:21

Using patience

I'm surprised no one else spoke about resolving conflict using patience with the merge recursive strategy. For a big merge conflict, using patience provided good results for me. The idea is that 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:

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
– Mathijs SegersSep 8 '17 at 7:55

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

Thank you for your interest in this question.
Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).