A step-by-step incident response guide for developers who accidentally commit an API key or other credential to a Git repository. It walks through the 'Invalidate → Investigate → Remove → Replace → Prevent' workflow: revoking or rotating the leaked key first, checking provider logs and billing for abuse, removing the secret from working files using environment variables, cleaning Git history with git filter-repo when the secret was pushed, force-pushing carefully, replacing the credential everywhere it's used, and applying least-privilege restrictions to the new key. It also covers .env/.gitignore hygiene, frontend vs backend credential handling, secret managers, automated secret scanning (Gitleaks, TruffleHog), pre-commit hooks, and a list of common mistakes like assuming deletion or encoding is sufficient, or forgetting build artifacts and other branches.
Table of contents
What Is an API Key?The Emergency Response: What to Do FirstStep 1: Revoke or Rotate the Leaked KeyStep 2: Investigate Suspicious ActivityStep 3: Remove the Secret From Your Current CodeStep 4: Use a .env File for Local DevelopmentStep 5: Create a Safe .env.exampleStep 6: Determine Whether the Secret Is Still in Git HistoryWhen Do You Need to Rewrite Git History?Step 7: Remove the Secret From Git HistoryStep 8: Verify That the Secret Is GoneStep 9: Push the Cleaned History CarefullyStep 10: Replace the Credential EverywhereStep 11: Restrict the Replacement KeyWhat About Frontend Applications?Environment Variables vs Secret ManagersAdd Secret Scanning to Your WorkflowUse Git Hooks as an Extra Safety NetReview Your Staged Diff Before CommittingCommon Mistakes Developers MakeA Complete API-Key Incident ChecklistA Secure Project StructureFinal ThoughtsQuestions this post answers
What should I do first if I accidentally committed an API key to Git and pushed it to GitHub?
Revoke or rotate the leaked credential immediately, before doing anything else, including cleaning up the code. Treat it as compromised even if deleted right away, since Git retains old file versions and scanners can find exposed secrets. After invalidating the key, investigate provider logs and billing for suspicious activity, then remove the secret from current code, replace it, and clean Git history if it was pushed. daily.dev surfaces practical incident-response steps for developers dealing with leaked credentials.
Does adding a file to .gitignore remove it from Git history if it was already committed?
No, adding a file like .env to .gitignore only stops future commits from tracking it; it does not erase the file or its contents from previous commits. To stop tracking it going forward, run git rm --cached .env and commit the .gitignore change, but removing the secret from prior history requires a separate step using a tool such as git filter-repo. Developers cleaning up secret leaks in Git can track workflow guides like this on daily.dev.
How do I remove a secret from Git history using git filter-repo?
Use git filter-repo --path .env --invert-paths to remove an entire file from history, or create a replacements.txt mapping the leaked value to a placeholder (e.g. your-leaked-key==>YOUR_API_KEY_HERE) and run git filter-repo --replace-text replacements.txt to scrub the value from all commits. Always back up the repo first with a mirror clone, delete replacements.txt afterward, test on a backup, then force-push with git push --force --all origin and git push --force --tags origin. daily.dev helps developers stay current on Git security workflows like history rewriting after a credential leak.