Three Ways to Ignore Files in Git (Beyond .gitignore)

A post on Hacker News today resurfaced something that many developers overlook: .gitignore is not the only way to ignore files in Git. There are actually three distinct mechanisms, each designed for different use cases. Understanding when to use which can clean up your repos and avoid awkward pull request feedback.

The Three Levels of Git Ignore

1. .gitignore (Shared, Committed)

The familiar option. Whatever patterns you add to .gitignore get committed to the repository and apply to everyone who clones it.

# .gitignore
node_modules/
dist/
.env

Use for: Build artifacts, dependencies, environment files - anything project-specific that no contributor should commit.

2. .git/info/exclude (Local, Per-Repository)

Located inside the .git directory, this file follows the same syntax as .gitignore but never gets committed. It's repository-specific and stays on your machine only.

# .git/info/exclude
my-local-notes.md
scratch/
debug.log

Use for: Personal scratch files, local test data, IDE configs that only you use, Makefiles or scripts specific to your dev environment.

3. ~/.config/git/ignore (Global, Machine-Wide)

A global ignore file that applies across every repository on your system. By default, Git looks for it at ~/.config/git/ignore, but you can point it elsewhere:

git config --global core.excludesFile ~/.gitignore_global

# ~/.config/git/ignore
.DS_Store
Thumbs.db
*.swp
.idea/

Use for: OS-specific cruft like .DS_Store on macOS or Thumbs.db on Windows. Also useful for editor-specific files you use across all projects.

Debugging Ignore Rules

When a file is being ignored and you're not sure why, Git has a built-in diagnostic:

git check-ignore -v myfile.txt

This outputs the file path, line number, and pattern responsible for ignoring the file. It's invaluable when you inherit a repo with complex ignore rules or when you're troubleshooting why something isn't showing up in git status.

What HN Is Saying

The Hacker News discussion (439 points, 137 comments) surfaced some practical patterns from experienced developers:

The "attic" pattern. Several commenters add attic to their global ignore, then create an attic/ directory in any project for random files that should never be committed. One commenter takes this further by putting a .gitignore inside the attic/ directory containing just * - making the directory self-ignoring.

The scope debate. There's a split on whether IDE/editor-specific ignores belong in the repo's .gitignore or your personal global config. The pragmatic argument: adding .idea/ or .vscode/ to every project's .gitignore saves everyone the trouble of configuring their global ignore. The purist argument: a repo's .gitignore should only contain patterns relevant to the project itself.

Devcontainer edge case. One commenter pointed out that global ignore files don't survive devcontainer rebuilds - you need to bind-mount your config or explicitly persist it.

The Magit angle. Emacs users noted that Magit has native support for choosing between shared (.gitignore) and private (.git/info/exclude) ignores when pressing i on a file.

The Decision Framework

Here's when to use each:

The key insight: if it's something every contributor would need to ignore, put it in .gitignore. If it's specific to your workflow but not the project, use the local or global options.

Why This Matters

Bloated .gitignore files are a code smell. When a repo's ignore file contains 50 lines covering every IDE, editor, and OS under the sun, it suggests nobody is using the right tool for the job. The result is a file that's hard to maintain and hides project-specific patterns in noise.

Knowing about .git/info/exclude and the global ignore file gives you cleaner repos and fewer "please remove your IDE config from the gitignore" code review comments.

Sources

• .gitignore Isn't the only way to ignore files in Git - Original article
• Hacker News Discussion - 439 points, 137 comments
• Git Documentation: gitignore - Official Git manual page