Introduction

Adding a file to .gitignore does not make Git forget a file that is already tracked. Once a path has been committed, Git continues to track it until you explicitly remove it from the index, even if the ignore rules now match it.

What .gitignore Actually Does

.gitignore only affects untracked files. It tells Git which new paths it should ignore when checking the working tree for files to add.

That means this sequence does not solve the whole problem by itself:

echo ".env" >> .gitignore
git add .gitignore
git commit -m "Ignore environment file"

If .env was already committed earlier, Git still tracks it. The ignore rule prevents future accidental git add operations on an untracked .env, but it does not retroactively untrack the file.

How to Stop Tracking an Already Committed File

To keep the file on disk but remove it from Git's index, use git rm --cached.

git rm --cached .env
git add .gitignore
git commit -m "Stop tracking .env"

After that commit:

• the file remains in your working directory
• Git stops tracking it
• future changes to that file are ignored if .gitignore matches it

For a whole directory:

git rm -r --cached build/
git commit -m "Stop tracking build output"

This is the standard fix.

A Concrete Example

Suppose you accidentally committed logs/app.log and later decide logs should be ignored.

Add the rule:

logs/

Then remove the tracked file from the index:

git rm -r --cached logs/
git add .gitignore
git commit -m "Ignore generated logs"

Now Git will stop showing new log changes in git status, because the path is both untracked and ignored.

When Sensitive Data Was Already Committed

Ignoring a file after commit is not enough if the file contains secrets. .gitignore only affects future tracking; it does not remove the file from commit history.

If secrets were committed, the real response usually includes:

1. rotating the exposed secret
2. removing the file from the current index with git rm --cached
3. optionally rewriting repository history if the leak must be removed from old commits

For history cleanup, modern Git recommends git filter-repo rather than older filter-branch workflows, but history rewriting needs coordination with everyone using the repository.

Global Ignore Versus Repository Ignore

Not every ignore rule belongs in the project. Personal editor files such as .DS_Store or local IDE settings often belong in a global ignore file instead.

Example:

git config --global core.excludesFile ~/.gitignore_global
echo ".DS_Store" >> ~/.gitignore_global

Use the repository .gitignore for files the entire team should ignore. Use a global ignore file for machine-specific clutter.

Debugging Ignore Behavior

If Git does not seem to honor an ignore rule, ask Git which rule applies:

git check-ignore -v .env

If nothing is printed, one of these is probably true:

• the file is still tracked
• the pattern does not match the path you think it matches
• the ignore rule is in the wrong file

You can also check whether Git still tracks the path:

git ls-files .env

If it appears in the output, it is tracked, and .gitignore alone will not change that.

Common Pitfalls

The biggest mistake is expecting .gitignore to untrack files automatically. It never has.

Another mistake is using git rm without --cached when you meant to keep the local file. Plain git rm deletes the file from disk as well as from the index.

Teams also add secret files to .gitignore and assume the incident is resolved, even though the secret remains in commit history. If credentials were exposed, rotate them first.

Finally, broad ignore patterns such as *.json or build* can hide files the project actually needs. Keep ignore rules specific enough to avoid collateral damage.

Summary

• '.gitignore only affects untracked files, not files that are already committed.'
• Use git rm --cached to stop tracking a file while keeping it on disk.
• If a directory is already tracked, remove it from the index with git rm -r --cached.
• For secrets, ignoring the file is not enough; rotate credentials and consider history cleanup.
• Use git check-ignore -v and git ls-files when ignore behavior seems inconsistent.