GitHub's guidance on leaked secrets puts rotation ahead of rewriting history

Rotation closes access. Once the token is revoked, the string sitting in the commit object opens nothing, and GitHub's page says revoking or rotating "may be sufficient to solve your problem" ^[2].

It takes only ordinary work to undo a rewrite: a developer with a clone from before it runs git pull, then git push, and the commits are back ^[4]. To avoid that, the developer has to discard the clone and re-clone, or walk the local copy through the cleanup steps first ^[5]. The page describes careful coordination with collaborators as a requirement for executing a rewrite at all ^[16].

Most of the remaining side effects land on people who did not leak anything: branch protections that block force pushes have to be turned off, at least temporarily ^[7]. Commit hashes change from the leaking commit forward, so tooling keyed to stable hashes breaks ^[6]. Closed pull requests lose their diff view, and not only the one that carried the secret: any PR built on later history loses it too, even when it modified no affected file ^[8]. On open PRs, comments anchored to the old diff may be invalidated and lost, so GitHub recommends merging or closing every open pull request before the removal ^[9]. If colleagues keep updating branches that contain the data while the cleanup runs, you either redo the cleanup or discard their work ^[13].

git-filter-repo strips commit and tag signatures, including on commits that pre-date the data being removed ^[10]. The page notes a workaround through the --refs option and the condition attached to it: you have to specify every ref that has the sensitive data in its history and that includes the introducing commits ^[11].

Order of operations matters more than tool choice here: Git's commit identifiers were built with cryptographic checks so that tampering on a server would be noticed, and the page states the consequence for data removal plainly, that users with an existing clone notice the divergence and can use it to find, quickly and easily, the data you removed from the central repository ^[12]. A rewrite done before revocation tells every clone holder where to look while the credential still works.

Count the bullets and the ratio is eight documented side effects against four high-level steps for doing the rewrite properly ^[15]. The third of those steps is coordinating with colleagues to clean up other clones that exist ^[14]. A force push reaches the central repository and stops there, and the page says the commits may remain accessible in clones and forks and directly via their SHA-1 hashes in cached views ^[3]. GitHub does not say how often revocation alone ends the incident; it says the secret case is the common one ^[1].