I thought I was safe.
My .gitignore had all the usual rules:
.env
.env.*
*.env
But one day, I discovered that my .env.dev and .env.prod files were exposed in a side project.
Here’s what I learned and what you should do if this ever happens to you.
1. .gitignore Doesn’t Undo History
Adding files to .gitignore only prevents future commits.
If a file was previously committed, Git will continue tracking it. That’s why changes to my .env.prod were still showing up.
👉 Lesson: .gitignore is not retroactive.
2. Immediate Response Matters
The moment you suspect a leak, act fast.
- Revoke exposed keys — treat them as compromised
- Rotate API keys, database passwords, tokens
- Redeploy applications with fresh secrets
- Audit logs for suspicious activity
👉 Assume the worst. Delay increases risk.
3. Cleaning Your Repository History
Deleting the file is not enough.
Sensitive data may still exist in past commits.
To fully remove it:
- Use tools like BFG Repo-Cleaner or
git filter-repo - Rewrite commit history
- Force push the cleaned repository
👉 This is the only way to truly scrub secrets.
4. Preventing Future Leaks
A few practices that help:
Double-check
.gitignorepathsAvoid storing critical secrets in
.envfiles-
Use secret managers:
- AWS Secrets Manager
- HashiCorp Vault
- GitHub Secrets
Educate your team: once committed, secrets persist unless explicitly removed
5. Stop Tracking Immediately
If a file is already tracked:
(after banging head multiple times)
git rm --cached .env
This removes it from Git tracking without deleting it locally.
Key Takeaway
.gitignore is not a safety net — it’s a guardrail.
If secrets leak:
Rotate → Clean → Monitor
Security isn’t about never making mistakes.
It’s about responding correctly when they happen.
If you’ve faced something similar, I’d love to hear how you handled it.
Top comments (1)
Thanks for sharing the important information on .gitignore