Revoke or rotate the secret first, before anything else. Once it cannot be used, the exposure is mostly closed. Removing it from history is a second, optional step, and it has real limits because forks, old clones and cached views may keep a copy.
Step one is not a git command
GitHub's guidance on removing sensitive data starts with revoking or rotating the credential, noting that once it cannot be used for access, that may solve the problem without rewriting history. A secret that has been pushed, even to a private repository or a pull request branch, should be treated as exposed. Closing the pull request or deleting the comment does not change that.
The response sequence
- Revoke or rotate the credential at the issuer.
- Check the issuer's logs for use between the time of the commit and the time of rotation.
- Decide whether rewriting history is worth it. For a revoked key, many teams stop here.
- If you rewrite, use a history rewriting tool and check the result before pushing.
- Tell collaborators and fix the cause so it does not recur.
If you rewrite history
GitHub's page describes using git-filter-repo, at version 2.47 or later for its sensitive data removal option. You can remove a file by path or replace specific strings across history. It suggests counting affected pull requests from the tool's output, and stopping if the number is unexpected, because the rewrite becomes irreversible after the force push.
The caveats it lists matter for planning:
| Caveat | Effect |
|---|---|
| Collaborators with old clones | They can reintroduce the data with a normal pull and push, so they must re-clone or rebase |
| Commit hashes change | Hash based tooling breaks |
| Signatures | Commit and tag signatures are removed |
| Open pull requests | Merge or close them first, since comments can be lost |
| Forks and cached views | May still hold the data |
For cached views and pull request references, GitHub says to contact its support. It also says support helps only with sensitive data that cannot be mitigated by rotating credentials, which is another reason rotation comes first. For forks, you contact the fork owners directly.
Preventing the next one
The same page suggests secret management tools, pre-commit scanners such as gitleaks, push protection and careful staging. In review, add a checklist line: no credentials, keys or tokens in the diff, test fixtures or sample config. Prefer a reference to a secret store over a value, even in examples.
A note on process
Decide in advance who may rotate which credentials. The delay in a real incident is usually finding the owner, not running the commands. A short runbook listing the issuer and owner of each credential type saves time.
Where Safeguard fits
Safeguard offers scanning and policies and gates that can be applied to pull requests, and a free scan at gold.safeguard.sh/scan. Rotation itself happens at each issuer.
Quick check
Is deleting the commit enough?
No. Forks, clones and cached views may still hold it. Rotate the credential first.
Do I always need to rewrite history?
No. GitHub notes that once the secret is revoked, that may solve the problem without a rewrite.
Sources
Last reviewed: 19 October 2026.
