An API key, password, or .env file is sitting in your GitHub repository. You
notice it yourself, a teammate spots it in review, or GitHub emails you a
"secret scanning" alert minutes after the push. Deleting the file and pushing
again does not help: the key is still visible in the old commits under the
repository's history tab.
First project that talks to a real service: a maps key, a payment-gateway sandbox
key from a UPI integration, an LLM API key from a college hackathon. The .env
file was committed because no .gitignore existed yet, or the key was pasted
straight into the code "for now". Public repos make it urgent — bots scrape GitHub
for fresh keys within minutes — but private repos are not safe either.
Linked module: 0.2 (Git & GitHub as an engineer).
Git history is append-only by design: every commit stores a full snapshot, and a
later commit that deletes the file does not touch the earlier ones. Anyone who can
see the repository can check out any old commit and read the key. Clones and forks
made before your cleanup keep their own full copies of history. Therefore the key
itself must be treated as burned the moment it was pushed — no amount of history
editing makes a leaked value secret again. Confirm the exposure: search the
history with git log --all -p -- .env or git log -S "<first-chars-of-key>" to
see every commit that contains it.
Order matters — rotate first, clean later. (1) Revoke or regenerate the key in the
provider's dashboard right now; this alone ends the danger. (2) Untrack the file:
git rm --cached .env, create a .gitignore containing .env, commit both, and
push. (3) If the team wants the value out of history too, rewrite it with a tool
like git filter-repo and force-push — only with the whole team's agreement,
since rewritten history breaks everyone's clones. (4) Tell your lead: at any
bank-grade company a leaked key is an incident with a process, and reporting it
fast is what a professional does.
Create .gitignore before the first commit, with .env in it from day one. Keep
secrets only in .env and commit a .env.example that names the variables with
fake values. Read the file list in git status before every commit — the habit
costs five seconds. Enable GitHub secret scanning and push protection on your
repos; they block many leaks at push time.
Q: "You realise a live API key went to GitHub an hour ago. What do you do, in
order?" Strong answer: rotate or revoke the key first and say why deletion commits
do not remove it from history, then untrack plus .gitignore, then optional
history rewrite with team consent, then report it. Naming the append-only design
and the clone/fork copies is what separates real understanding from a memorised
checklist.