Introduction

If you want to see which files Git is ignoring, git status --ignored gives a broad view. If you want to know exactly why a specific path is ignored and which ignore rule caused it, git check-ignore -v is the more precise command.

Core Sections

Use git status --ignored for an overview

This command shows ignored files alongside the normal repository status output.

git status --ignored

It is useful when you want a quick answer to questions like:

• is this directory being ignored at all
• which ignored files are currently present in the working tree
• is the ignore pattern broader than I expected

The output is good for scanning, but it does not always tell you the exact pattern responsible for each file.

Use git check-ignore -v for the exact rule

When the real question is “which .gitignore entry is causing this file to be ignored,” use:

git check-ignore -v path/to/file

The -v flag prints the source ignore file, line number, and matching pattern.

git check-ignore -v build/output.log

That makes it the best debugging command for ignore behavior.

Understand what .gitignore can and cannot do

.gitignore affects untracked files. If a file is already tracked by Git, adding it to .gitignore does not make Git forget it.

For example, if config.local.json is already committed, this ignore rule will not stop Git from noticing changes:

config.local.json

To stop tracking it, remove it from the index first while keeping the file in your working directory.

git rm --cached config.local.json

Then the ignore rule can take effect for future untracked states.

Patterns can come from more than one place

Git ignore behavior does not come only from the repository’s root .gitignore. A file can be ignored because of:

• the root .gitignore
• a nested .gitignore inside a subdirectory
• '.git/info/exclude'
• the global ignore file configured in Git settings

That is another reason git check-ignore -v is valuable. It tells you which file and line actually matched.

A practical debugging sequence

When a file seems to “disappear” from Git, a reliable sequence is:

1. run git status --ignored to confirm it is being ignored
2. run git check-ignore -v path/to/file to identify the source rule
3. check whether the file is already tracked
4. adjust the pattern or untrack the file if necessary

That sequence resolves most .gitignore confusion quickly.

Example patterns and exceptions

*.log
build/
!important.log

In this example:

• any .log file is ignored
• everything under build/ is ignored
• 'important.log is re-included if the surrounding directory structure allows it'

This is where the exact-match diagnostic becomes helpful, especially when negation rules interact with broader patterns.

Common Pitfalls

• Using git status alone and assuming a missing file is ignored without checking ignored output explicitly.
• Forgetting that .gitignore does not affect files Git is already tracking.
• Debugging only the repository root .gitignore even though a nested ignore file, exclude file, or global ignore rule may be responsible.
• Asking “why is this file ignored” with git status --ignored when git check-ignore -v is the command that answers that question precisely.
• Misreading negation rules such as !file and expecting them to work when parent directories are still excluded in a conflicting way.

Summary

• Use git status --ignored to see ignored files broadly.
• Use git check-ignore -v path to see the exact ignore rule and source file.
• '.gitignore applies to untracked files, not files already committed to the index.'
• Ignore behavior can come from local, nested, repo-specific, or global sources.
• The fastest way to debug ignore issues is to combine broad status inspection with exact rule tracing.