What belongs into .gitignore (and what doesn’t)

There’s a high chance that your .gitignore file includes a bunch of stuff which doesn’t belong in there. In my opinion, it should only include paths which belong to your software project. For example build artifacts, 3rd party packages, and specifics to the language or runtime of your software.

You’ll also often find paths for Editors and Operating Systems inside .gitignore. Let’s say you’re using VS Code on macOS, so you added this to your .gitignore:

.vscode
.DS_Store

The next developer joining the project uses IntelliJ on Windows, so they update the .gitignore to this:

.vscode
.DS_Store
.idea
Thumbs.db

The neat thing about software projects is that they’re completely independent from your local setup. You can use whatever Operating System and Editor you want. So why do we break this by adding details about our local environments into the project?

Define a global .gitignore

Of course Git has a solution for this. You can define a global gitignore file, only locally for you.

To do this, create a new file ~/.config/git/ignore and add all paths specific to your local setup into it. For VS Code on macOS, it could look like this:

.vscode
.DS_Store

And you’re done. It will be applied to all projects, additionally to the .gitignore of each project.

At the time of writing, I’m using asdf which has a .tool-versions files, so I can specify which Node.js version I want in a specific project. Of course not everyone is using asdf, so I simply added it to my global gitignore.

Un-ignoring still works

Let’s say your team decided to share some common VS Code configurations, but your global gitignore already contains the .vscode folder and won’t be checked in. No worries, overrides will still work. If you un-ignore it inside the .gitignore of the project, it will be checked in again – only for this project, and not for all.

!.vscode/tasks.json
!.vscode/launch.json

It’s their fault

A lot of auto-generators and project templates come with a .gitignore file which already contains such common paths for local setups. This might make it more beginner friendly, but I think it also makes it look like it’s the solution on how to deal with those files. But it’s not.