How to resolve a binary file conflict with Git

When performing a merge in git, you might see the message:

warning: Cannot merge binary files: HEAD:somefile.dll vs. otherbranch:somefile.dll

Auto-merging somefile.dll
CONFLICT (content): Merge conflict in somefile.dll
Automatic merge failed; fix conflicts and then commit the result.

In this scenario, somefile.dll is a binary file that has been modified in both the current branch, and the branch you are attempting to merge in to the current branch. Since the file cannot be textually merged, you need to make a decision: do you keep the version of the file in your current branch, or the version in the other branch.

In TortoiseSVN, I was used to being able to right-click on the file in question and choose “Resolve using mine”, or “Resolve using theirs”. So what is the git equivalent?

Resolve using mine

The file in your working copy is still the copy from your current branch – in other words, it was not modified by the merge attempt. To resolve the conflict and keep this file:

git add somefile.dll 
git commit –m “My commit message for the merge”

Resolve using theirs

If you prefer to resolve the conflict using their copy, you need to get the version of the file from the branch you were trying to merge in:

git checkout otherbranch somefile.dll

Now that you have the correct version of the file in your working copy, you can mark it as resolved (by adding it), and commit:

git add somefile.dll
git commit –m “My commit message for the merge”

Note that in place of otherbranch, you can use any name (treeish) that refers to a branch: a local branch name (otherbranch), a remote branch name (origin/master), a specific commit SHA (980e3cc), etc. For example, if you were merging in from your remote when you received the conflict, and you wanted to resolve using the remote version, you would retrieve that copy of the file using:

git checkout origin/master somefile.dll



You then add the file and commit as described above.

UPDATE: There is a shortcut for getting the copy from the other branch (and it even uses the terminology I was expecting):

git checkout --theirs -- somefile.dll

Related Articles:

This entry was posted in git. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • http://elijahmanor.com Elijah Manor

    Thanks. I just started using git not too long ago. I haven’t run into this message yet, but I am sure I will soon. Thanks for the insight!

    This will be tech tweeted tomorrow morning at 9am cst ;)

  • http://blogs.dovetailsoftware.com/blogs/kmiller Kevin Miller

    Thank you for figuring this out. This means that I messed up and did the git equivalent of Resolve Using Mine when I wanted the opposite. Looks like I’ll use your post to fix that.

  • roleic

    The described approach seems useful for a single one or only few binary files in conflict. How can this approach be efficiently used with a large number of binary files in conflict distributed in a large tree mixed with text files?

  • Skydiver

    git status –porcelain | sed -r -e ‘s/…(.*)/git checkout –theirs ./1/’ >../tmp
    mv ../tmp .
    ./tmp
    rm tmp

    this work’s for me.

  • Richard

    When trying to resolve a binary conflict that occurred during a git rebase, I use

    git rebase master -s recursive -X theirs, which will favour the checked out branch’s changes (IE, not master’s changes) when resolving conflicts.