A file in .gitignore still shows changes: check whether Git already tracks it

By ON Lab · Sources checked November 8, 2026

Adding a path to .gitignore does not stop Git tracking a file already in its index. First check whether the exact file is tracked. If the team intends to stop distributing it, review a targeted git rm --cached -- path/to/file change together with the ignore rule. That operation keeps your working copy but stages its removal from the repository.

A reported symptom, not necessarily a broken ignore pattern

A GitHub Desktop reader reported that ignored files kept appearing as changed. A contributor explained that a previously committed file needed to be removed from the index. The official Git documentation makes the same distinction: ignore rules describe intentionally untracked files and do not affect tracked ones.

That distinction prevents two unnecessary fixes: repeatedly changing a correct pattern, or clearing the whole index when only one file needs review. A file can match the intended rule and still be tracked. Conversely, an untracked file can remain visible because its rule does not match.

Inspect one exact path before changing anything

git status --short
git ls-files --error-unmatch -- path/to/file
git diff -- path/to/file
git diff --cached -- path/to/file

Run each command separately. The ls-files check lists the exact tracked path and succeeds when it is in the index. A nonzero result needs its error read; it is not automatically proof that the file should be deleted. Check spelling and the current repository first.

The two diff commands inspect different comparisons. The ordinary diff shows working-tree changes relative to the index. The cached diff shows staged changes relative to the current commit. Read both if someone has staged part of the file already. Do not add force flags to bypass a refusal without understanding which version would be removed from the index.

Check the ignore rule independently

git check-ignore -v -- path/to/file
git check-ignore -v --no-index -- path/to/file

By default check-ignore does not report tracked files because they are not subject to exclusion. Its no-index option lets you investigate the rule without that tracked-file filter. In our local example, the ordinary command printed nothing for the tracked file, while the no-index command identified the matching .gitignore line.

Verbose output includes the source, line, pattern, and path. Read the pattern too: a leading exclamation mark is a negation, so the appearance of output alone is not enough to conclude that a file is excluded. Directory boundaries and nested .gitignore files also matter. Use the source line rather than looking for the filename anywhere in the rules.

If the file should stop being tracked

Preserve the useful local contents first. Confirm that removing the repository copy is the intended team change; configuration templates and required project files may need to remain tracked. Then use the exact path, not a whole-repository cache-clearing recipe:

git rm --cached -- path/to/file
git diff --cached --name-status
git diff --cached -- path/to/file
git status --short --ignored

The cached option removes the path from the index while leaving the working file. The staged diff should show the intended repository deletion. The ignore rule prevents the local file being added again through a later ordinary add operation; it does not commit the change for you. Review the complete staged diff and the matching rule before committing.

Do not silently escalate to git rm without cached: that changes the working tree as well. Also avoid broad recursive untracking when a single path is the problem. A command refusing to proceed may be protecting staged content that differs from both the current commit and working file.

What the disposable reproduction established

We created a local repository with a committed local-settings.txt, added a matching rule, and changed the file. Git still reported the tracked modification. We checked index membership and the rule separately, then removed only that file from the index with cached.

The working file retained its changed contents, the staged diff reported a deletion, and reading HEAD:local-settings.txt still returned the original committed contents. Thus untracking did not erase the file's history. No remote, real credential, project file, or global Git setting was changed.

History and teammates are separate checks

A future commit removing the path does not remove earlier copies from history. If the file contained an exposed secret, treating .gitignore as a security repair is insufficient; follow the affected service's credential response and the repository's approved history-management process. This guide does not rewrite history or rotate credentials.

Other checkouts will receive the committed repository deletion through their normal update process. Do not promise that cached preserves every teammate's local copy: the cached operation preserves the working file where you ran it. Coordinate the repository change and provide an appropriate example configuration when needed.

Finish by confirming the intended local file still exists, the staged change contains only the approved paths, and subsequent local edits behave as expected. A clean changes panel alone does not prove that the right repository contents remain.

Official sources and the reader issue checked November 8, 2026. The tracked-file, ignore-rule, targeted untracking, and historical-copy checks were executed in a disposable local repository. GitHub Desktop's current UI and teammate update behavior were not reproduced.