How do you fully remove leaked credentials from Git history?

WHAT THIS TESTS: This question probes whether you understand that rewriting public Git history is a destructive, team-wide incident requiring choreography, not a solo git command. It separates engineers who know the tool from senior engineers who can manage the blast radius.

A GOOD ANSWER COVERS: First, rotate or revoke the exposed credential immediately so the secret is dead regardless of history cleanup. Second, announce a branch freeze and ask every developer to stop pushing. Third, use git-filter-repo, not filter-branch, to purge the file from all commits in the local clone. Fourth, force-push the rewritten main branch, which requires temporarily lifting branch protection rules. Fifth, ask every teammate to delete their local clone and re-clone fresh rather than attempting git pull, because a pull-and-push from a stale clone recontaminates the repository with the old commits. Sixth, verify the secret is gone by searching git log and using the GitHub secret scanning API or web interface. Seventh, re-enable branch protections and document the incident.

COMMON WRONG ANSWERS: Suggesting git revert is the most common mistake because it adds a new commit but leaves the credential in history where it remains searchable. Another error is rewriting history without rotating the secret first, which means the credential is still valid during the cleanup window. A third red flag is ignoring branch protection or failing to coordinate the team, leading to immediate recontamination when another developer pushes their old main.

LIKELY FOLLOW-UPS: How would you handle this if the repository had two hundred forks? What if a developer has an open pull request branched from the old history? How do you audit whether the secret was accessed or exploited before revocation? Would you use BFG Repo-Cleaner instead of git-filter-repo, and why?

ONE CONCRETE EXAMPLE: Imagine a .env file containing an AWS secret access key was committed to main in commit abc123 and three subsequent feature merges landed on top. You would immediately rotate the AWS key in IAM, then run git-filter-repo --path .env --invert-paths on a fresh clone to strip the file from every commit. After force-pushing main, you would ask all twelve engineers to rm -rf their local repo and git clone again. You would also check that any CI pipelines referencing commit abc123 by hash are updated, because the rewritten history generates new SHAs.

Source: docs.github.com