Git's .gitignore file is a staple in every developer's toolkit, but most teams rely on only one mechanism to prevent unwanted files from being committed. A recent discussion on Hacker News highlighted two Git ignore files that are widely overlooked: the global .gitignore and the per-repository exclude file at .git/info/exclude. Understanding these can streamline your workflow and reduce repository clutter.

What You Need to Know

Git offers three levels of ignore files: the project-level .gitignore (shared with the team), the global ~/.gitignore_global (personal to your machine), and the repository-level .git/info/exclude (local to your clone and not shared). Most developers only use the first, leaving the other two untapped. Using all three helps separate personal editor artifacts from shared rules, preventing accidental commits of OS files, IDE settings, or sensitive credentials without polluting the team's ignore list.

Understanding Git's Ignore Mechanisms

Git's ignore rules cascade across three levels. The project .gitignore is the most familiar: it lives in the repository root and is committed to version control. This file should contain patterns that apply to everyone on the team, such as build output directories (node_modules/, target/) or generated files.

The other two levels are personal. The global ignore file, typically located at ~/.gitignore_global, allows you to set patterns that apply across all your repositories on that machine. This is the right place for editor-specific files like .vscode/, .idea/, or OS artifacts such as .DS_Store. The local exclude file at .git/info/exclude works like a private .gitignore for a single repository clone and is never shared with anyone. It is ideal for temporary or sensitive files you want to keep out of a specific repo without altering the shared ignore list.

  • Global .gitignore: Configured via git config --global core.excludesFile ~/.gitignore_global. Apply rules to every repo on your machine.
  • Local exclude file: Located at .git/info/exclude. Follows the same syntax as .gitignore but stays local to your clone.

Why This Matters

Neglecting these two files leads to common problems: team members commit personal IDE files, OS metadata, or even credentials because the project .gitignore was never updated. When developers add patterns to the shared .gitignore for personal tools, everyone else must pull those changes, creating unnecessary noise and merge conflicts. By using global and local ignore files, teams keep shared rules clean and developers maintain their own preferences without friction. This also reduces the risk of accidentally leaking sensitive information, as a local exclude file can block a credential file without broadcasting its existence.

How to Adopt These Files

Adding the global ignore file is straightforward. Run git config --global core.excludesFile ~/.gitignore_global and populate it with your personal patterns. For the local exclude file, simply edit .git/info/exclude inside any repository that needs private rules. Both files use standard gitignore syntax, so there is no new syntax to learn.

Adopting these two overlooked files transforms how you manage Git ignores. The project .gitignore remains lean and team-focused, while your machine and clone handle the rest. This small habit shift leads to fewer accidental commits, cleaner repos, and a more professional version control practice.