Introduction

When Git does not ignore a file you listed in .gitignore, the problem is usually not that .gitignore is broken. The real cause is almost always one of a few specific rules: the file is already tracked, the pattern does not match the path you think it matches, or a later rule re-includes it. Once you know how Git evaluates ignore rules, the behavior becomes predictable.

The Most Common Cause: The File Is Already Tracked

.gitignore only affects untracked files. If Git already knows about the file, adding it to .gitignore does not make Git forget it.

You can see this with a simple workflow:

1git add .env
2git commit -m "Track env file"
3echo ".env" >> .gitignore
4git status

The file still appears because it is already in the index. To stop tracking it while keeping it on disk, remove it from the index:

git rm --cached .env
git commit -m "Stop tracking env file"

After that, the .gitignore rule starts applying to future changes.

Make Sure the Pattern Actually Matches

Git ignore patterns are path-sensitive. A rule that looks right at a glance may still miss the file.

Examples:

1# Ignore every log file anywhere
2*.log
3
4# Ignore only the root-level config file
5/config.local.json
6
7# Ignore every build directory
8build/

A few matching rules matter a lot:

• '*.log matches log files in many locations'
• '/file.txt matches only at the repository root'
• 'temp/ matches a directory named temp'
• '**/temp/ is useful when you need a recursive pattern'

If the file lives in src/config/settings.local.json, then a rule for /settings.local.json will not match it.

Debug with git check-ignore

The fastest way to understand why a file is or is not ignored is to ask Git directly:

git check-ignore -v src/config/settings.local.json

If the file is ignored, Git prints the matching ignore file and rule. If nothing prints, the file is not currently being ignored.

This command is especially helpful when several ignore files are involved, such as:

• the repository's .gitignore
• '.git/info/exclude'
• a global ignore file configured in your Git settings

Re-Including Files with !

Git lets you negate an ignore rule with !. That is useful, but it can also create confusion if you forget a later rule overrides an earlier one.

*.log
!important.log

In that example, most log files are ignored, but important.log is brought back.

There is one subtlety: if a parent directory is ignored, Git may never descend into it to see a later negation rule unless the directory itself is also handled carefully.

Global and Local Ignore Sources

Not every ignore rule comes from the repository. You might also have a global ignore file configured through Git:

git config --global core.excludesfile

That file is often used for editor files, OS metadata, or local tooling noise. It can explain behavior that is not obvious from the repository's own .gitignore.

Common Pitfalls

• Adding a tracked file to .gitignore and expecting Git to stop tracking it automatically.
• Writing the wrong pattern for the file path, especially with root-relative rules.
• Forgetting that later rules can override earlier ones.
• Ignoring a parent directory and then wondering why a negated child rule does not work.
• Debugging by guesswork instead of using git check-ignore -v.

Summary

• '.gitignore only affects untracked files.'
• If a file is already tracked, use git rm --cached before the ignore rule will help.
• Pattern syntax matters, especially with leading slashes and directory rules.
• Use git check-ignore -v to see exactly which rule is applying.
• Check repository, local, and global ignore sources when behavior seems inconsistent.