Git allows you to provide .gitignore files specifying intentionally untracked files that Git should ignore.

For anything I work on, I usually have two such files; a “repository .gitignore” in the repo root (which appears fairly common), and a “personal .gitignore”.

Why two? I see it as separation of concerns.

The personal ignore is for files I make through my own choices (e.g. due to my tooling).

I used IntelliJ IDEA for some time, and it leaves *.iml files around, so I ignore those. I use OSX, which leaves .DS_Store files around, so I ignore those. If I hand-create a virtualenv I tend to make it in .env, so I ignore that.

My tools, my choices, so I make sure they don’t make a mess.

On the other hand, the repository .gitignore I use for files the repository makes. So if its test suite runs with coverage, ignore the .coverage output directory; if it ships a Vagrantfile then ignore .vagrant etc.

The biggest downside I see is that I’ve shifted the burden of work; if you’re new, if you’re unfamiliar with git, you may not have a personal .gitignore, and that’s totally ok. “We put everything in our repo .gitignore to be more welcoming” feels like a completely legitimate position; I’d personally rather just link people to this post.

TL;DR

I believe that:

• A repository should have a .gitignore that covers all the files the repository tooling may generate
• You should have a personal ignore file that covers all the files your personal tooling choices may generate

I don’t want PRs for the dozen-or-so different IDEs and editors etc. that people may happen to use!