You committed an API key by accident. You noticed, deleted the line, and committed again. The current code is clean. The key is still there, and anyone who clones your repo can get it in one command.
Git never forgets
Git stores the full history of every change. "Deleting" a secret in a later commit does not remove the earlier commit that added it. The value sits in the object database, and git log -p or a history-scanning tool will surface it instantly.
Why this matters more for small projects
Indie repos go public more casually, get shared as portfolio pieces, and rarely have anyone auditing history. A secret that lived in a commit for ten minutes two years ago is still a live credential today if it was never rotated.
The only real fix for a committed secret is to rotate it. History surgery removes the evidence, not the risk.
What to actually do
- Rotate the secret immediately. Assume it is compromised the moment it was committed.
- Scan your full git history, not just the working tree, for keys and high-entropy strings.
- If you must purge history, use a tool built for it, then force-push and rotate anyway.
Catch it before it ships
The cheapest fix is not committing the secret in the first place. Scanning both your current source and your git history before a release turns "we found it two years later in a breach report" into "we caught it on Tuesday."