Resolving a Git conflict with binary files

git checkout accepts an --ours or --theirs option for cases like this. So if you have a merge conflict, and you know you just want the file from the branch you are merging in, you can do:

$ git checkout --theirs -- path/to/conflicted-file.txt

to use that version of the file. Likewise, if you know you want your version (not the one being merged in) you can use

$ git checkout --ours -- path/to/conflicted-file.txt

You have to resolve the conflict manually (copying the file over) and then commit the file (no matter if you copied it over or used the local version) like this

git commit -a -m "Fix merge conflict in test.foo"

Git normally autocommits after merging, but when it detects conflicts it cannot solve by itself, it applies all patches it figured out and leaves the rest for you to resolve and commit manually. The Git Merge Man Page, the Git-SVN Crash Course or this blog entry might shed some light on how it's supposed to work.

Edit: See the post below, you don't actually have to copy the files yourself, but can use

git checkout --ours -- path/to/file.txt
git checkout --theirs -- path/to/file.txt

to select the version of the file you want. Copying / editing the file will only be necessary if you want a mix of both versions.

Please mark mipadis answer as the correct one.

To resolve by keeping the version in your current branch (ignore the version from the branch you are merging in), just add and commit the file:

git commit -a

To resolve by overwriting the version in your current branch with the version from the branch you are merging in, you need to retrieve that version into your working directory first, and then add/commit it:

git checkout otherbranch theconflictedfile
git commit -a

Explained in more detail

I came across a similar problem (wanting to pull a commit that included some binary files which caused conflicts when merged), but came across a different solution that can be done entirely using git (i.e. not having to manually copy files over). I figured I'd include it here so at the very least I can remember it the next time I need it. :) The steps look like this:

% git fetch

This fetches the latest commit(s) from the remote repository (you may need to specify a remote branch name, depending on your setup), but doesn't try to merge them. It records the the commit in FETCH_HEAD

% git checkout FETCH_HEAD stuff/to/update

This takes the copy of the binary files I want and overwrites what's in the working tree with the version fetched from the remote branch. git doesn't try to do any merging, so you just end up with an exact copy of the binary file from the remote branch. Once that's done, you can add/commit the new copy just like normal.

This procedure is to resolve binary file conflicts after you have submitted a pull request to Github:

1. So on Github, you found your pull request has a conflict on a binary file.
2. Now go back to the same git branch on your local computer.
3. You (a) re-make / re-build this binary file again, and (b) commit the resulted binary file to this same git branch.
4. Then you push this same git branch again to Github.

On Github, on your pull request, the conflict should disappear.

I use Git Workflow for Excel - https://www.xltrail.com/blog/git-workflow-for-excel application to resolve most of my binary files related merge issues. This open-source app helps me to resolve issues productively without spending too much time and lets me cherry pick the right version of the file without any confusion.

my case seems like a bug.... using git 2.21.0

I did a pull... it complained about binary files:

warning: Cannot merge binary files: <path>
Auto-merging <path>
CONFLICT (content): Merge conflict in <path>
Automatic merge failed; fix conflicts and then commit the result.

And then nothing in any of the answers here resulted in any output that made any sense.

If I look at which file I have now... it's the one I edited. If I do either:

git checkout --theirs -- <path>
git checkout --ours -- <path>

I get output:

Updated 0 paths from the index

and I still have my version of the file. If I rm and then checkout, It'll say 1 instead, but it still gives me my version of the file.

git mergetool says

No files need merging

and git status says

    All conflicts fixed but you are still merging.
    (use "git commit" to conclude merge)

One option is to undo the commit... but I was unlucky and I had many commits, and this bad one was the first. I don't want to waste time repeating that.

so to solve this madness:

I just ran

git commit

which loses the remote version, and probably wastes some space storing an extra binary file... then

git checkout <commit where the remote version exists> <path>

which gives me back the remote version

then edited the file again...and then commit and push, which again probably means wasting space with another copy of the binary file.