Introduction

Git ignore rules are easy until you need an exception. The usual case is straightforward: ignore generated files, logs, or secrets. The tricky part is keeping one specific file tracked while the broader pattern remains ignored.

The ! Negation Rule

In .gitignore, an exclamation mark re-includes a path that was ignored by an earlier rule. Order matters, so the exception must come after the ignore pattern it overrides.

*.log
!important.log

With this configuration, every .log file is ignored except important.log.

The same idea works for directories:

config/*.local.json
!config/default.local.json

This is the standard answer to a "git ignore exception" question: ignore a broad set of files, then add a more specific negated pattern for the file you want to keep.

Directory Exceptions Need an Extra Step

A common source of confusion is that Git does not descend into an ignored directory looking for exceptions unless the directory itself is visible. That means ignoring a whole directory and then trying to re-include a file inside it usually fails unless you also re-include the path leading to that file.

Use this pattern instead:

build/*
!build/keep/
!build/keep/config.example.json

Here is what happens:

• 'build/* ignores everything under build'
• '!build/keep/ makes that subdirectory visible again'
• '!build/keep/config.example.json re-includes the specific file'

If you write only build/ and then try to unignore a nested file, Git will often never reach it because the directory itself is excluded from traversal.

Example: Keep a Placeholder File

A very common pattern is to ignore generated files in a directory but keep a placeholder so the directory exists in the repository.

uploads/*
!uploads/.gitkeep

Now the uploads directory can stay in source control through .gitkeep, while the runtime-generated files remain ignored.

That same pattern is frequently used for cache directories, log directories, and local storage folders.

What If the File Is Already Ignored?

After changing .gitignore, you may still need to add the file explicitly if Git currently considers it ignored. The -f flag forces Git to stage it.

git add -f config/default.local.json

This is helpful when you are introducing a new exception rule and want to make sure the intended file becomes tracked immediately.

Once the file is tracked, .gitignore no longer controls updates to it. Ignore rules primarily affect untracked files.

Repository Ignore Versus Global Ignore

Git also supports a global ignore file configured per developer. That is useful for machine-specific clutter such as editor swap files or operating-system metadata.

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

Use repository .gitignore files for project rules that everyone should share. Use the global ignore file for personal environment noise. If you need an exception that other contributors also depend on, put it in the repository, not only in your global config.

A Safe Mental Model

The easiest way to reason about ignore exceptions is:

1. Write the broad ignore rule first.
2. Add the more specific ! rule after it.
3. If the file is inside an ignored directory, re-include the parent path as needed.
4. Force-add the file once if Git still does not pick it up.

That mental model prevents most .gitignore debugging sessions.

Common Pitfalls

• Placing the ! rule before the ignore rule. Later patterns can override earlier ones.
• Ignoring an entire directory with dir/ and expecting a nested exception to work automatically.
• Forgetting that .gitignore does not stop changes to files that are already tracked.
• Using git add -f without adding a matching negation rule. That stages the file once, but the config stays confusing.
• Putting team-wide ignore exceptions only in a global ignore file, where other developers cannot see them.

Summary

• Use !path in .gitignore to create an exception to an earlier ignore rule.
• Put exception rules after the broader ignore patterns they override.
• Re-include parent directories when the kept file lives inside an ignored tree.
• Use git add -f if you need to stage an ignored file after changing the rules.
• Keep shared ignore exceptions in the repository so the whole team gets consistent behavior.