What still exists after you rewrite Git history to remove a secret

Rewriting history with git filter-repo removes a secret from your branches, but not from every place it was copied. Other clones, forks, cached views and pull request references can still expose it. That is why GitHub tells you to rotate the credential first and treat the rewrite as cleanup.

The order GitHub recommends

GitHub's documentation puts rotation at the front: revoke or rotate the secret before doing anything else. If the credential no longer works, you may not need a rewrite at all. GitHub Support also only helps with removal when rotating cannot reduce the risk.

If you do rewrite, GitHub recommends the git-filter-repo tool. Its sensitive data removal flag needs version 2.47 or later.

The shape of the rewrite

In outline:

1. Clone the repository fresh.
2. Remove the file by its full path, or replace the text listed in a file of patterns.
3. If the file was moved or renamed at some point, remove its other paths too.
4. Push the rewritten refs with a mirror force push.

git filter-repo --invert-paths --path secrets/prod.env
git push --force --mirror origin

Check the tool's own help for the exact flags in your version before running anything, and do it on a fresh clone so nothing local is lost.

What the push cannot reach

GitHub lists the leftovers plainly.

• Pull request references. Pushes to the read-only pull request refs fail, so affected pull requests can keep the old commits reachable until GitHub Support dereferences or deletes them.
• Cached views. The data may still be viewable by commit SHA until Support removes the cached views.
• Other clones and forks. You cannot delete them. Collaborators must clean up their own copies, and fork owners have to be contacted by you, because GitHub cannot hand over their contact details.

If protected branches block the force push, GitHub notes you may need to disable branch protection temporarily, then restore it straight after.

What collaborators must do

Anyone with a clone of the old history should not merge their branches into the rewritten one. GitHub tells collaborators to rebase onto the new history and to clean up or re-clone. A merge brings the old commits, and the secret, straight back.

Send that instruction the same day as the rewrite, and name the old and new head commits so people can tell which history they hold.

What to contact Support with

For leftover pull request data and cached views, GitHub asks for the repository name, the number of affected pull requests, the first changed commits from the tool's output, and details of any orphaned LFS objects. Collect those before you write in.

Quick check

Safeguard can scan your repositories for dependency and code risks, and the free scan at gold.safeguard.sh/scan needs no setup. For the full response sequence, see the leaked secret response steps.

Sources

• Removing sensitive data from a repository, GitHub Docs

Last reviewed: 19 October 2026.