Introduction

If Git is ignoring a file and you want to know exactly why, the right tool is not manual inspection of every .gitignore file. Git can tell you the matching rule directly, including the source file and line number.

The command to remember is git check-ignore -v. It is the fastest way to explain which ignore rule matched a path.

Use git check-ignore -v

Run the command with the file path you care about:

git check-ignore -v path/to/file.txt

Example output looks like this:

.gitignore:12:*.log	logs/app.log

That line tells you:

• the ignore source file
• the line number
• the exact pattern that matched
• the path you asked about

This is much better than guessing which pattern won.

Git Can Ignore from Several Places

The matching rule may come from more than one location. Common sources are:

• a repository .gitignore
• a nested .gitignore in a subdirectory
• '.git/info/exclude'
• a global excludes file configured in Git settings

That is another reason the command matters. The active rule might not be in the .gitignore file you were staring at.

Check a Directory or Several Files

You can ask about multiple paths at once:

git check-ignore -v .env build/output.bin src/generated/data.json

This is useful when you are debugging a group of files and want to see whether one pattern or several different rules are involved.

Tracked Files Are Different

A common confusion is that .gitignore affects only untracked files. If a file is already tracked, adding it to .gitignore later will not make Git stop tracking it.

If that happens, remove it from the index first:

git rm --cached path/to/file.txt

Then the ignore rule can take effect for future status checks.

Negation Rules Matter Too

Git ignore rules can be negated with !. That means a later rule can re-include something that an earlier rule excluded.

For example:

*.log
!important.log

In cases like this, git check-ignore -v helps you confirm which final rule actually controlled the result. Ignore debugging is really precedence debugging.

Directories Can Hide Files Indirectly

Sometimes the file itself does not have a matching pattern, but one of its parent directories does. For example, if build/ is ignored, then build/output/report.txt is ignored because the directory is ignored. That is another reason to ask Git directly instead of scanning for the filename only. The effective rule may target a directory pattern rather than the exact file path.

Once you know the source line, the fix is usually obvious: remove the rule, narrow the pattern, or add a negation rule if the file should be re-included.

That feedback loop is much faster than editing several ignore files blindly.

Common Pitfalls

• Scanning .gitignore manually instead of using git check-ignore -v.
• Forgetting that ignore rules can come from global excludes or .git/info/exclude.
• Expecting .gitignore to hide files that are already tracked.
• Missing the effect of later negation rules such as !important.log.
• Debugging from the wrong working directory and passing the wrong relative path.

Summary

• Use git check-ignore -v path/to/file to see exactly which ignore rule matched.
• Git reports the source file, line number, and pattern.
• Ignore rules can come from repository, nested, local, or global sources.
• '.gitignore does not automatically stop tracking files already in the index.'
• Most ignore-rule mysteries become obvious once you use the built-in command.