GitHub Docs Remove Sensitive Data from Repository History Git Filter-repo
To follow github docs remove sensitive data from repository history git filter repo, rewrite commits locally. Then force push the clean history back to your remote host. Teams often do this after a developer commits a plain text password or key. Broad repo permissions make this worse because any member can pull the leaked secret. Once someone clones the repo, that secret sits on their local machine forever. How github docs remove sensitive data from repository history git filter repo works Gi
Git Commit Signing (GPG, SSH) + GitHub Actions Security: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
To follow github docs remove sensitive data from repository history git filter repo, rewrite commits locally. Then force push the clean history back to your remote host. Teams often do this after a developer commits a plain text password or key. Broad repo permissions make this worse because any member can pull the leaked secret. Once someone clones the repo, that secret sits on their local machine forever.
How github docs remove sensitive data from repository history git filter repo works
Git stores every version of every file inside its hidden folder as immutable snapshots. When you delete a file in a new commit, the old snapshot still exists. Anyone with read permissions can check out an older commit and read the secret. Standard deletion only hides the file from the latest view of your branch.
The filter repo tool fixes this by scanning every commit from the very beginning. You give the tool a target path or a text string to find. It walks through the commit graph and removes the matching file or text string. Then it builds a brand new commit history without the bad data.
Because commit hashes depend on content, every changed commit gets a new hash. Your local repo now has a clean history that diverges from the remote repo. You must force push all branches and tags to overwrite the remote history. Every teammate must then delete their old local clones and fetch the new history.
Why cleaning git history is only half the fix
Scrubbing git history removes the secret from future clones of your code repo. Still, you must always assume a leaked key is already stolen and compromised. Automated bots scan public and private repos for keys within seconds of a push. Pull requests, forks, and build logs may also hold copies of the old commit.
Git permissions only decide who can read or push code to a repo. They do not control what happens when someone uses a leaked database key. If a developer stores a database password in code, anyone can take it. That person can then log in directly to your database and run bad commands.
First, revoke and rotate every leaked password or token right away in your systems. Next, stop handing out static database keys and server passwords to developers. If engineers do not hold raw credentials, they cannot commit them to git.
Git Commit Signing (GPG, SSH) + GitHub Actions Security: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
Coordinating the cleanup across your team
Rewriting repo history breaks active branches for everyone else on your engineering team. Before you run the cleanup tool, ask all developers to pause their work. Merge or close open pull requests so you do not lose good code changes.
After you force push the clean branches, cached copies still remain on the server. You must contact support or clear old pull request refs to drop those commits. Tell every engineer to rebase or make a fresh clone of the project. If one person pushes an old branch, the deleted secret comes right back.
You should also add secret scanning rules to block future leaks before they merge. Good pre-commit checks catch keys on the laptop before a developer runs a push. Pairing local checks with zero static credentials keeps your repo history clean for good.
Check database and API queries on the wire
Identity tools, roles, and network rules decide who opens a session. Setup alone cannot check what each query does or mask sensitive values in a response once a session starts. When workflows touch Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes APIs, SSH, or internal HTTP APIs, hoop.dev runs beside those services as an open-source proxy, a sidecar for your Postgres or API. It inspects requests coming in and results going back on the wire.
Your login details and client tools stay as they are while hoop.dev guardrails refuse bad deletes or drops before they run. On responses, hoop.dev data masking rewrites matched sensitive values in memory. Furthermore, hoop.dev holds SOC 2 Type II, is MIT licensed, and writes every query and decision to an audit trail that generates evidence for HIPAA, GDPR, and PCI DSS. See the source on GitHub.
Frequently asked questions
Do I still need to rotate a secret after I remove it from git?
Yes, you must rotate any leaked password or API key right away. Cleaning git history does not erase copies from old clones or build logs. Always treat a committed secret as fully exposed to outside attackers.
Why does git filter repo replace git filter branch?
The older filter branch tool runs very slow on large code bases. It is also easy to make mistakes that leave old refs behind. The newer filter repo tool runs much faster and cleans history more safely.
What happens if a teammate pushes an old branch after the cleanup?
Pushing an old branch puts the dirty commits right back into your remote repo. You would have to run the cleanup and force push all over again. Make sure every developer deletes their old local branches before they push code.