Git: Keeping Files from Being Tracked Without .gitignore

noelworden profile image Noel Worden Updated on ・2 min read

This week I picked up a little gem around keeping files out of git.

I had made some tasks via VSCode and in doing so it created a .vscode file in the workspace. Git picked up this new file, so I instinctively went for .gitignore. I added .vscode with a small comment, committed, and pushed up a PR.

A colleague pointed out that .gitignore wasn't the best place for this file, because it was developer environment-specific and not project-specific. But he didn't stop there, he pointed me to another git dotfile that I didn't know existed!

Before I get into that dotfile, a little refresher on accessing dotfiles. If you're navigating to this file via the terminal, the basic ls command won't show dotfiles, it needs to be appended with -a, so the command is ls -a.

If you're on a Mac and navigating via the Finder, by default you won't see dotfiles either. Here's a one-liner you can run in terminal to show the dotfiles:

There are actually two actions happening in that command, the first is telling the OS to set AppleShowAllFiles to YES.

And the second is restarting the Finder app. When it completes the restart it will show all dotfiles, system-wide.

Ok, now, back to the git stuff.

When a git repository has been created, with git init, it installs this .git folder, which contains everything git needs to track files, run hooks, etc. A little buried in that folder is a file titled exclude, found at this path:

.git > info > exclude

That exclude file basically acts as a .gitignore, but at a local level. So, in my case I just added .vscode, and, like git magic, it's ignored in my tracked files.

This post is part of an ongoing This Week I Learned series. I welcome any critique, feedback, or suggestions in the comments.

Posted on by:

noelworden profile

Noel Worden


Software Engineer in Boulder, CO - Writing code and getting strategically lost in the mountains


Editor guide

I would stick to .gitignore for excluding project files, precisely because .gitignore is committed and propagated. And you actually want to make sure everybody has them excluded, otherwise if someone has theirs committed and pushed, it'll mess up others' local setup when they pull it. Remember info/exclude is local per repo, meaning every time someone clones a repo, they need to remember to manually edit the file. That is very error-prone.