Introduction

Every developer has editor-specific files, OS artifacts, and personal tooling output that should never be committed. Rather than polluting the shared .gitignore with patterns only relevant to your machine, Git provides two mechanisms for user-specific ignore rules: a global ignore file and a per-repo local exclude file. This article explains both approaches, when to use each, and how they interact with the committed .gitignore.

The Three Layers of Git Ignore

Git evaluates ignore patterns from three sources, in order of increasing specificity:

1. Global ignore file -- applies to every repository on your machine.
2. Repository .gitignore -- committed and shared with all collaborators.
3. Local exclude file -- applies to a single repository, not committed.

A file is ignored if it matches a pattern in any of these layers. Understanding which layer to use prevents cluttering the shared .gitignore with patterns that only matter to one developer.

Setting Up a Global Ignore File

The global ignore file covers patterns that follow you across all repositories, such as OS metadata and editor configuration directories.

Step 1 -- Create the File

touch ~/.gitignore_global

Step 2 -- Register It with Git

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

This writes the setting to ~/.gitconfig. You can verify it with:

git config --global core.excludesFile
# output: /Users/yourname/.gitignore_global

Step 3 -- Add Your Patterns

Open the file and add patterns for your environment:

1# macOS
2.DS_Store
3.AppleDouble
4.LSOverride
5
6# JetBrains IDEs
7.idea/
8*.iml
9
10# VS Code
11.vscode/
12*.code-workspace
13
14# Vim / Neovim
15*.swp
16*.swo
17*~
18
19# Thumbnails and caches
20Thumbs.db
21*.log

Every repository you clone or create will now ignore these files without any per-repo configuration.

Per-Repository Local Exclude

Sometimes you need to ignore files in a single repository without affecting others and without modifying the committed .gitignore. Git stores a local exclude list at .git/info/exclude.

# Open the exclude file in your editor
vim .git/info/exclude

Add patterns exactly as you would in a .gitignore:

1# personal test scripts
2scratch/
3my_notes.txt
4
5# local environment overrides
6.env.local
7docker-compose.override.yml

Because this file lives inside the .git directory, it is never committed and never visible to collaborators. This makes it ideal for one-off experiments, local configuration overrides, or temporary build artifacts that only exist on your workstation.

Choosing the Right Layer

Use the following decision tree to decide where a pattern belongs:

1Is the pattern relevant to all developers on the project?
2  YES -> .gitignore (committed)
3  NO  -> Is it relevant to all your repositories?
4           YES -> ~/.gitignore_global
5           NO  -> .git/info/exclude

For example, node_modules/ belongs in the committed .gitignore because every contributor needs it. .DS_Store belongs in your global ignore because it is a macOS artifact unrelated to the project. A scratch/ folder you created for local experimentation belongs in .git/info/exclude.

Using core.excludesFile with a Custom Path

The core.excludesFile setting accepts any absolute path, so you can store your global ignore file wherever you like:

git config --global core.excludesFile ~/dotfiles/gitignore

This is useful when you keep your dotfiles in a version-controlled repository and symlink them across machines. The ignore patterns travel with your dotfiles, ensuring consistent behavior on every workstation.

Handling Already-Tracked Files

A common source of confusion is that ignore rules only apply to untracked files. If a file is already tracked by Git, adding it to any ignore file has no effect. You must explicitly untrack the file first:

1# Stop tracking a file without deleting it from disk
2git rm --cached path/to/file
3
4# Stop tracking an entire directory
5git rm -r --cached path/to/directory

After untracking, the ignore pattern takes effect and Git will no longer show the file as untracked in git status.

Debugging Ignore Rules

When a file is not being ignored as expected, use git check-ignore to find out why:

# Show which rule is matching (or not matching) a path
git check-ignore -v path/to/file

The output includes the source file, line number, and pattern:

/Users/you/.gitignore_global:3:.DS_Store    .DS_Store

If there is no output, no ignore rule matches the file. Add the -n flag to also show non-matching paths:

git check-ignore -v -n path/to/file

Common Pitfalls

• Adding OS-specific patterns to the shared .gitignore. Patterns like .DS_Store or Thumbs.db belong in your global ignore file, not in the project .gitignore where they create noise for developers on other platforms.
• Expecting ignore rules to untrack committed files. Git ignore only prevents untracked files from being staged; run git rm --cached first for already-tracked files.
• Forgetting to set core.excludesFile. Creating ~/.gitignore_global without registering it via git config --global core.excludesFile means Git will not read it.
• Using relative paths in core.excludesFile. The setting requires an absolute path or a path starting with ~/; a bare relative path resolves differently depending on the working directory.
• Overriding patterns unintentionally. A negation pattern (!important.log) in .gitignore can re-include files that your global ignore would otherwise exclude; review all layers when debugging unexpected behavior.

Summary

• Use ~/.gitignore_global with core.excludesFile to ignore editor, OS, and tooling artifacts across all repositories.
• Use .git/info/exclude for ignore patterns that apply to a single repository without being shared with collaborators.
• Reserve the committed .gitignore for patterns that every developer on the project needs.
• Already-tracked files must be untracked with git rm --cached before ignore rules take effect.
• Debug unexpected behavior with git check-ignore -v to see exactly which rule and file is matching.