Adding a file to .gitignore does nothing for a file Git already tracks, and nothing for the commits that already contain it. The secret stays in history and in every clone. The fix is to rotate the credential first, then stop tracking the file, then decide whether history needs a rewrite.
What .gitignore actually does
The Git manual states that files already tracked by Git are not affected by ignore patterns. The ignore file only decides which untracked files Git will offer to add. Once a path is in the index, Git keeps tracking changes to it whatever the ignore file says.
That is why the common sequence goes wrong. Someone commits a .env file, notices, adds .env to .gitignore, and commits again. The file is still tracked, and the first commit still holds the values.
Stop tracking without deleting the local copy
The manual describes the way to stop tracking a file: remove it from the index, then add the name to the ignore file so it does not come back.
git rm --cached path/to/.env
echo 'path/to/.env' >> .gitignore
git commit -m "Stop tracking local env file"
This protects future commits only. Anyone who clones the repository can still check out an older commit and read the file.
Treat the value as exposed
Once a secret has been pushed, assume someone could have copied it. GitHub's own guidance on removing sensitive data says to revoke or rotate the credential first, because once it no longer grants access, much of the problem is gone. A rewrite of history does not undo copies that already exist in clones and forks.
Rotate, then clean up. The reverse order leaves a working credential exposed while you tidy.
Pick the right ignore file
Not every ignore rule belongs in the shared file. The manual lists three places:
.gitignorein the repository, shared with everyone who clones..git/info/exclude, for patterns that matter only on your machine and are not shared.- The file named by
core.excludesFile, for patterns that apply to all your repositories, such as editor backup files.
Putting your personal editor files in the global file keeps the shared one short, which makes a missing secrets pattern easier to spot in review.
Keep the secret out of the working tree
Ignore rules are a safety net, not a storage plan. Keep real values in a secrets manager or in environment variables supplied at run time, and commit a sample file with placeholders such as .env.example. Add a scan that fails when a known credential format appears in a commit, so a mistake is caught before the push rather than after.
Quick check
I added the file to .gitignore. Is the secret safe now?
No. If the file was committed before, ignore rules do not apply to it and the old commits still contain the value. Rotate the credential.
Does removing a file from the index delete it from my disk?
No. It removes the file from the index only, so your local copy stays in place and is simply no longer tracked.
If you want to see what a scanner finds in your dependencies and code today, the free scan at gold.safeguard.sh/scan is a quick way to start.
Sources
Last reviewed: 19 October 2026.
