Robin van der Vleuten

Keep personal files out of your project .gitignore

You're reviewing a pull request and everything looks normal until one small line turns up in the diff:

 node_modules/
 public/build/
+ .idea/

Harmless enough, maybe.

But it also says something about the boundary between project configuration and personal configuration. The project probably does need to ignore node_modules/ or generated build output. It probably doesn't need to know which editor I use.

That belongs on my machine, not in everybody's repository.

Two kinds of ignored files

I used to treat .gitignore as the place for everything Git shouldn't track. That is technically true, but it hides an important distinction.

There are two different lists:

  • Files the project creates.
  • Files my computer creates.

Those are not the same thing.

Project files are things every contributor will run into: dependency folders, compiled assets, temporary cache directories, test output, logs, uploads, local build artifacts. They belong in the repository's .gitignore because they describe how the project behaves.

Personal files are different. macOS leaves .DS_Store behind. Editors create .vscode/, .idea/, swap files, workspace metadata, and local history folders. Maybe you use .envrc for direnv. Maybe nobody else on the team does.

The repository doesn't need to care.

The better place for personal clutter

Git has a setting for this: core.excludesfile.

It points Git at a global ignore file on your machine. Anything you always want Git to ignore can live there once, instead of getting added to every project you touch.

I keep mine in my home directory:

touch ~/.gitignore
git config --global core.excludesfile ~/.gitignore

Then fill it with files that are about your environment, not the project:

# macOS
.DS_Store

# Editors
.idea/
.vscode/
*.swp

# Local tools
.envrc

That's it.

From then on, those files disappear from git status in every repository. You stop adding .DS_Store to random projects. Editor folders stop showing up in pull requests. Your local workspace metadata stays local.

Keep project ignores boring

A good project .gitignore should be boring in a specific way: another developer should be able to read it and understand what the project itself produces.

For a Rails app, that might mean entries like these:

/log/*
/tmp/*
/storage/*
/public/assets
.byebug_history

Those entries make sense because Rails creates them, or because the app expects them to be local runtime state.

Your editor choice doesn't have that property. Neither does the operating system metadata your laptop leaves around. Once those personal rules land in the repository, everybody inherits them, even if they don't use the same tools.

That is how project ignores turn into little records of every contributor's setup.

Check what Git is using

If you forget where your global ignore file lives, ask Git:

git config --global core.excludesfile

And if a file is being ignored but you don't know why, git check-ignore can show the matching rule:

git check-ignore -v .vscode/settings.json

That command is especially useful when a file vanishes from git status and you can't remember whether the rule came from the project, your global file, or somewhere else.

What belongs where

The rule I try to follow is simple:

If the project creates it, ignore it in the project. Build output, logs, caches, uploaded files, generated assets, local databases. These rules help every contributor.

If your machine creates it, ignore it globally. Editor folders, OS metadata, swap files, local shell tooling. These rules follow you around without leaking into shared history.

If it's secret, don't rely on ignore rules alone. .env files often belong in .gitignore, but the real fix is still to keep secrets out of Git from the start. Ignore files prevent accidents. They don't erase history.

It is a small setup step, but it removes a surprising amount of noise. Your commits stay narrower, pull requests stop carrying personal workspace details, and project .gitignore files stay about the project.

That is the whole point: shared config should describe the project, not everybody's laptop.