Skip to content

Instantly share code, notes, and snippets.

@tmaybe
Last active June 14, 2025 16:59
Show Gist options
  • Save tmaybe/4c9d94712711229cd506 to your computer and use it in GitHub Desktop.
Save tmaybe/4c9d94712711229cd506 to your computer and use it in GitHub Desktop.
ignoring merge conflicts for specific files in a git repository

How to Ignore Merge Conflicts for Specific Files in a Git Repository

Create a directory and git init it

$ mkdir merge-test
$ cd merge-test/
$ git init

Create some simple content and commit it. When we're done, the contents of one directory will generate a conflict, the contents of the other will not.

$ mkdir allow-conflict
$ mkdir ignore-conflict
$ echo a > allow-conflict/index.txt
$ echo b > ignore-conflict/index.txt
$ git add -A
$ git commit -m 'initial commit'

Check out a new branch and modify the content of both files. This branch will represent the 'local' branch.

$ git checkout -b local-branch
$ echo a-my-conflicting-content >> allow-conflict/index.txt 
$ echo b-my-conflicting-content >> ignore-conflict/index.txt 
$ git add -A
$ git commit -m 'add content in local branch'

Check out another new branch and modify the content of both files. This branch will represent the 'remote' branch.

$ git checkout master
$ git checkout -b remote-branch
$ echo a-their-conflicting-content >> allow-conflict/index.txt 
$ echo b-their-conflicting-content >> ignore-conflict/index.txt 
$ git add -A
$ git commit -m 'add content in remote branch'

Let's verify that at this point, trying to merge the two branches will generate conflicts for both files.

$ git checkout local-branch
$ git merge remote-branch

You'll see this conflict message:

Auto-merging ignore-conflict/index.txt
CONFLICT (content): Merge conflict in ignore-conflict/index.txt
Auto-merging allow-conflict/index.txt
CONFLICT (content): Merge conflict in allow-conflict/index.txt
Automatic merge failed; fix conflicts and then commit the result.

Now let's tell git to ignore the conflict in ignore-conflict/index.txt. First, reset so we can try the merge again.

$ git reset --hard

Create a .gitattributes file in ignore-conflict that says only index.txt merge=ours

$ echo index.txt merge=ours > ignore-conflict/.gitattributes

Define an "ours" merge strategy in the git config.

$ git config merge.ours.driver true

(if you cat .git/config at this point, you'll see at the bottom:)

[merge "ours"]
    driver = true

Try to merge the branches again,

$ git merge remote-branch

and we'll see only one conflict.

Auto-merging allow-conflict/index.txt
CONFLICT (content): Merge conflict in allow-conflict/index.txt
Automatic merge failed; fix conflicts and then commit the result.

Success!

Sources:

http://git-scm.com/book/en/v2/Customizing-Git-Git-Attributes#Merge-Strategies http://stackoverflow.com/a/930495/958481

@FlightControl-User
Copy link

Although all this is interesting, i personally prefer at this moment to focus my available time on functionality. Investing hours to efficiently create a time stamp is a bit too much time spent from my side.
Also, a commit should be efficient, smooth, and without workarounds if possible.
We came from a commit process where every time we had to regenerate a complete file before every commit and it was too much overhead, and on top, it was creating unwanted conflicts when dealing with merges.
I will look into the idea above but want to question the urgency of this requirement.

@FlightControl-User
Copy link

And before I forget to mention. Thanks for checking all of this. It looks comprehensive.

@Timothy626
Copy link

Thanks for the write up. Exactly what I was looking for!

@ramyaramdasan
Copy link

Hi,

Thanks for the informative write-up. Are these merge strategies that we define using CLI also valid on GitHub.com?

@andrew-sayers
Copy link

I've just adapted this for use on the Debian wiki. Thanks for the inspiration! I made some some changes that might interest you:

Calling the driver "ours" is a good analogy with the merge strategy of the same name, but the documentation made me think driver = true was setting a boolean flag ("yes, enable support for the built-in 'ours' strategy"), not calling a program ("the custom 'ours' driver runs /usr/bin/true"). The wiki page tries to clarify that.

Putting the attribute in .gitattributes but the configuration in .git/config creates a bit of a footgun. If you commit .gitattributes and push your repo, other people will be unable to pull changes unless they know to add the driver. The wiki page puts the change in .git/info/attributes instead.

On the wiki page, click the "comments" link near the top of the page, then scroll down just below the example to see the link back here. I've hidden the link by default because I'm concerned it will distract a casual reader, but can make it more explicit if that's better.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment