.gitignore not working? Check rules and tracked files

You add a filename to .gitignore, but it stays in Git’s change list. Or a file you want to add never appears in git status. Looking only at the ignore pattern can hide the difference between these two situations.

Start with the file’s tracking state, then find the rule that matches its path. This gives you a smaller change to investigate before touching the index. With Git for Windows, you can run the following commands in PowerShell from the relevant repository. Replace app.log with the path you want to inspect.

Inspect the file’s status

git status --short --ignored -- app.log

!! app.log means the file is ignored; ?? app.log means it is untracked. A tracked file can have a different status indicating an addition or modification. A tracked file without changes may not appear in this status listing at all.

Find the matching rule and line number

git check-ignore -v -- app.log

For an untracked app.log, a repository-root .gitignore with *.log on its first line can produce:

.gitignore:1:*.log	app.log

The fields identify the rule’s source file, its line number, the pattern, and the path being checked. A tab separates the pattern from the path. Rules can also come from a nested .gitignore, .git/info/exclude, or a user-wide exclusion file. Reading the source shown here helps you find the setting that actually applies.

No output can mean that the path does not match a rule. However, tracked files are also omitted by default, so check tracking before assuming the pattern is wrong.

Check whether the file is already tracked

git ls-files --error-unmatch -- app.log

If the path is in the index, Git prints it and returns exit code 0. If it is absent, the command reports an error and returns 1. That result does not mean the untracked file was damaged.

.gitignore controls intentionally untracked files. Adding a pattern does not remove a file that has already been added to the index. To check whether an ignore rule would match a tracked path without considering its index entry, use:

git check-ignore -v --no-index -- app.log

Here, --no-index changes what this check considers. It does not remove the file from the index or change its tracking state. A rule appearing in this output therefore does not establish that Git has started ignoring the tracked file.

Read exceptions and parent-directory rules

For example, these two .gitignore lines exclude log files while making keep.log an exception:

*.log
!keep.log

git check-ignore -v -- keep.log

Verbose output can show the exception pattern !keep.log too. Output alone is therefore insufficient to decide that a file is excluded. Read the leading ! and compare it with the file’s status.

If the parent directory itself is excluded, an exception for a file inside it cannot bring that file back. Excluding the directory with logs/ and matching its contents with logs/* have different consequences for later exception rules. Inspect the matching line and the parent-directory rule before changing either.

Choose the change that matches the diagnosis

For an untracked file that cannot be added, investigate the matching exclusion rule. For a tracked file that keeps appearing as changed, investigate its tracking state. You do not need to re-add an entire repository just to understand why one path appears in a list.

If you have just staged content you want to take back out, see unstaging a file while keeping your edits. Unstaging changes and ending tracking of a committed file are different operations. Adding .gitignore also does not remove a file from earlier commits; handling a secret already published in history requires a separate response.

Once you have chosen the content to commit, git diff –check can inspect whitespace in staged and unstaged changes.

References

• Git: git check-ignore
• Git: gitignore
• Git: git ls-files
• Git: git status