How do you fully remove leaked credentials from Git history?
This tests Git history rewriting and incident response. Rotate the secret first, then use git-filter-repo to purge the file, force-push main, and require all teammates to re-clone before resuming. A red flag is recommending git revert or skipping rotation.
What's really being asked
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.
The full answer
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.
The mistakes people make
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.
What usually comes next
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?
A 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.
Interview question
After force-pushing a Git history rewritten with git-filter-repo to remove leaked credentials, why must teammates delete their local clones and re-clone rather than pull?
- a.A pull-and-push from their stale local branch would recontaminate the remote with the old commits containing the secretCorrect
- b.Their local reflog retains the old commits, which could resurface the secret during a later merge
- c.git-filter-repo changes commit timestamps so git pull produces irreconcilable merge conflicts
- d.Branch protection rules invalidate existing tracking branches until manually re-enabled on each clone
Why? this is the answer
The card explicitly warns that a teammate who pulls and then pushes from a stale local clone will reintroduce the old commits containing the secret back to the remote. While reflogs retain local history, the critical blast radius is recontamination of the shared repository, not a local merge issue.
Just read this? Test yourself on what you have been reading.
Read the original → docs.github.com
- #git
- #security
- #incident-response
- #ci/cd
- #version-control
You just looked this up. Could you explain it out loud?
That is the part interviews actually test. Tezvyn takes questions like this one and gives you what the interviewer is really checking, the answer that lands, and the mistake that ends the conversation, in the four minutes before your next meeting.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Open roles that interview on git — each one lists the topics its interview covers.
See open roles