Committed a Secret? Purge Git History Properly
Rotate first, rewrite second. Why deleting the file does nothing, how filter-repo actually purges, and the scanner that stops the next leak.
Short answer
Rotate or revoke the secret first. Then rewrite history with git filter-repo and force-push carefully. Deleting the file in a new commit leaves the secret in history.
Why delete is not enough
Git keeps old blobs. Clones, forks, and CI caches may still hold the key.
Anyone who cloned before your "delete" commit still has the secret. Rotation is the only reliable kill switch.
Readers skimming committed secret purge git often stop at definitions. The part that prevents incidents is the verification step after the change - and the habit of re-checking after the next deploy that touches the same layer.
Order of operations
Revoke, rewrite with git filter-repo (or equivalent), coordinated force-push, invalidate CI caches, add pre-commit secret scanning.
Skip the order and you will "fix" git while the key still works in production.
Common failure mode for committed secret purge git: staging looks fine, production still serves the old config because a CDN, load balancer, or second vhost was never updated. Always verify the hostname customers hit.
Prevent the next one
Secret scanning in CI, pre-commit hooks, and never pasting keys into tickets or chat.
Treat a committed secret as an incident with a postmortem, not a oops commit message.
If this section on committed secret purge git becomes a recurring ticket, automate the check. Manual one-offs rot; a post-deploy assertion or weekly grade keeps the control honest.
What to do this week
- Revoke/rotate the exposed secret immediately.
- Rewrite history; coordinate force-push with the team.
- Invalidate CI caches and redeploy with new secrets.
- Enable pre-commit or CI secret scanning today.
Rotate first. Rewrite second. Scanners after.
Update log (1)
2026-06-23Editorial form rewrite for length and uniqueness.
Sources + verification
Practical guidance based on mainstream browser behavior, common reverse-proxy configuration, and widely published RFCs and vendor docs. Verify on your own stack with curl, browser devtools, and a re-scan after each change.
