The Secret You Committed Is Still in the History

You committed an API key. You noticed within a minute, deleted the line, and committed again. The key is still there — in the previous commit, in every clone, and in every fork.

Deleting the line does nothing. The only fix is to rotate the credential, and the only prevention is a hook that stops the commit before it happens.

The response, in order

Rotate first. Before cleaning history, before anything else. Assume it is compromised — automated scrapers watch public commits and act within minutes. Revoke, issue a new one, deploy.

Then check for use. Provider logs, unusual requests, unexpected charges. Rotating without checking leaves you unaware of what happened in between.

Then decide about history. Rewriting is disruptive on a shared repository and, for a public repo, does not undo forks or caches. If the credential is rotated it is dead anyway. Rewrite when there is a compliance reason; otherwise prioritise rotation.

The prevention

gitleaks protect --staged

As a pre-commit hook, this refuses to commit when a staged change matches a secret pattern. It is fast enough that nobody notices it running.

Then run gitleaks detect in CI so a bypassed hook still gets caught, and once across full history when you take over an existing codebase. That last one has a high hit rate — most repositories with a few years of history contain something.

Reducing the chances structurally

Never let a real credential exist in a file that could be committed. .env in .gitignore from the first commit, with a .env.example holding only key names.

Use short-lived credentials where the provider offers them. A token valid for an hour is a much smaller incident.

Give each environment its own key. A leaked development key that cannot touch production is an inconvenience rather than an emergency.

Never send secrets over chat. This is how most client credentials actually leak in small teams — not through git at all. A secrets manager with an invite is barely more effort than a message.

The client conversation

When I take over a project, secret scanning across history is one of the first things I run, and it usually finds something. Reporting it well matters: what was found, whether it is still valid, what to rotate, and in what order.

That first report tends to be the moment a client understands what "we take security seriously" means in practice.

Resources

• Repo: gitleaks/gitleaks
• Video walkthroughs: YouTube: Gitleaks tutorial
• Verification-based alternative: TruffleHog
• Where secrets belong: Infisical