.gitignore Mistakes That Leak Secrets Into Git History
Why adding a file to .gitignore after it's already been committed doesn't do what people expect, and what actually removes a leaked secret.
Published April 11, 2026
A surprising number of leaked API keys and database credentials trace back to the same sequence: a .env file or config file got committed once, early in a project, before .gitignore was set up properly. Adding the file to .gitignore afterward feels like it should fix the problem. It doesn't, and understanding why matters more than the .gitignore file itself.
Why .gitignore doesn't retroactively fix anything
.gitignore only tells git which untracked files to leave alone when staging new changes. It has zero effect on files git is already tracking, and it has zero effect on history: a secret committed in an early commit is still sitting in that commit, readable by anyone who clones the repository and checks out or browses that point in history, even after the file gets deleted or ignored going forward.
What actually needs to happen
Two separate things: stop tracking the file going forward (git rm --cached, then commit, then .gitignore prevents it from coming back), and treat the leaked secret itself as compromised, rotate it. Rewriting git history to scrub the secret from old commits is possible but genuinely disruptive for anyone else with a clone of the repo, and it still doesn't guarantee the secret was never cached, forked, or scraped somewhere in the meantime. Rotating the credential is the only step that actually closes the exposure; removing it from history is cleanup, not the fix.
The habit that prevents this
Set up .gitignore before the first commit that could possibly include a secret, not after. A project's .env, credentials, and local config files should never exist as untracked-but-visible files even once; that one early gap is exactly the window this whole problem lives in.