Keep personal files out of your project .gitignore
You're reviewing a pull request and everything looks fine until one tiny line sneaks into the diff:
diff
Harmless, right?
Maybe. But it also tells you 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's technically true, but it's not specific enough.
There are really 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 a little .envrc for direnv. Maybe I don't.
The repository doesn't need to care.
The better place for personal clutter
Git has a setting for this: core.excludesfile.
It's a global ignore file that applies to every repository on your machine. Anything you always want Git to ignore can live there once, instead of being added to every project you touch.
I like keeping mine in my home directory:
sh
Then fill it with the files that are about your environment, not the project:
# macOS .DS_Store # Editors .idea/ .vscode/ *.swp # Local tools .envrc
Done.
From that point on, those files disappear from git status everywhere. No more adding .DS_Store to random repositories. No more editor folders in pull requests. No more pretending your workspace metadata is a shared project concern.
Keep project ignores boring
A good project .gitignore should be boring in a very specific way: another developer should be able to read it and understand what the project itself produces.
For a Rails app, that might be things like:
/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 the same property. Neither does the operating system metadata your laptop sprinkles around. Once those personal rules land in the repository, everybody inherits them, even if they don't use the same tools.
That's how project ignores turn into little museums of every contributor's machine.
Check what Git is using
If you ever forget where your global ignore file lives, ask Git:
sh
And if a file is being ignored but you're not sure why, git check-ignore can show the matching rule:
sh
That command is especially handy when a file disappears 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's a small setup step, but it cleans up a surprising amount of noise. Your commits get narrower, your pull requests stop carrying personal workspace details, and your project .gitignore stays about the project.
No more drive-by editor folders. No more .DS_Store whack-a-mole. No more turning shared config into a diary of everybody's laptop.