All posts

I wiped an entire column of customer data by mistake, and it was already in git

I wiped an entire column of customer data by mistake, and it was already in git. The commit was clean. The tests passed. But the branch was poisoned with sensitive fields that should have never been there. The problem with sensitive columns in source control is that they spread. Every clone, every branch, every pull. Once they land in the history, they're permanent unless you cut them out. Git reset is not enough. You must remove the sensitive columns from every commit they touched, and you mu

Free White Paper

DPoP (Demonstration of Proof-of-Possession) + Data Masking (Dynamic / In-Transit): The Complete Guide

Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.

Free. No spam. Unsubscribe anytime.

I wiped an entire column of customer data by mistake, and it was already in git.

The commit was clean. The tests passed. But the branch was poisoned with sensitive fields that should have never been there. The problem with sensitive columns in source control is that they spread. Every clone, every branch, every pull. Once they land in the history, they're permanent unless you cut them out.

Git reset is not enough. You must remove the sensitive columns from every commit they touched, and you must do it without breaking the integrity of your codebase. This means rewriting history, not just rolling back.

The fastest way is using git filter-repo or the old git filter-branch. Identify the column or key—let’s call it ssn—and strip it from all revisions. This is not just about redacting; it’s about deleting it from the repository’s DNA. Every commit that contained that column must be rewritten, and any collaborator must re-clone from scratch once you force push the cleaned branch.

Here’s the clean kill in git filter-repo:

Continue reading? Get the full guide.

DPoP (Demonstration of Proof-of-Possession) + Data Masking (Dynamic / In-Transit): Architecture Patterns & Best Practices

Free. No spam. Unsubscribe anytime.
git filter-repo --path path/to/file.csv --replace-text replacements.txt

Where replacements.txt contains:

ssn==[REMOVED]

Then verify. Diff the cleaned repo against a fresh install. Search with grep for any trace of the sensitive value. Only when it is truly gone do you push, replacing the remote history.

Be aware: cleaning the main branch is not enough. Tags, archived branches, forks, and backups can still serve the sensitive data to anyone. Hunt them all down. Remove, replace, push again.

The best way to avoid all of this: never let sensitive columns into git in the first place. Add strict pre-commit hooks that scan for dangerous data. Run automated checks in CI. Log nothing that wouldn’t be safe on a public screen.

Mistakes happen fast. So should recovery. Tools that catch and strip sensitive values before they hit the commit are no longer optional—they’re essential. That's where Hoop.dev shines. You can set it up in minutes and see it running live, stopping leaks before you need a nightmare git reset ever again.

Get started

See hoop.dev in action

One gateway for every database, container, and AI agent. Deploy in minutes.

Get a demoMore posts