One bad commit can expose everything

That’s how sensitive data leaks happen. An API key, a password, a private certificate—pushed without a second thought, buried deep in history, and cloned to the world. You can delete the file, but Git never forgets. Until you tell it to.

Why Git reset alone won’t save you
A simple git reset just changes HEAD. It doesn’t rewrite the history where the secret first appeared. Anyone with a copy, or even access to your remote, can still see the data. Real removal from history needs tools that surgically alter the commit tree.

How to remove sensitive data from Git history

1. Identify the exposure
   Find the exact file or string, and locate the commit hash.
2. Use git filter-repo or BFG Repo-Cleaner
   These tools rewrite repository history, deleting the file or replacing secrets wherever they appear.
3. Force push cleaned history
   Use git push --force to update the remote.
4. Invalidate the exposed secret
   Change passwords, regenerate API keys, or rotate certificates immediately.
5. Invalidate old clones
   Anyone with an old clone has the secret in plain sight. Notify, revoke, and require fresh clones from the cleaned repository.

Example with git filter-repo

git filter-repo --path yourfile.txt --invert-paths

This removes all history of yourfile.txt. Replace yourfile.txt with the file containing sensitive data.

Best practices to avoid this again

• Add .env and secret files to .gitignore
• Use pre-commit hooks to scan for keys
• Centralize secrets in a secure vault
• Automate scans in CI/CD

Sensitive data in Git is a high-risk incident. The longer it sits in history, the greater the impact. Immediate action is not optional—it’s the only move.

If you need to see this fixed and shipped to production in minutes, try it on hoop.dev. You can set up, test, and validate the clean repository instantly—no rebuilds, no waiting.