The database wasn’t.
You just rebased a branch. Code was flawless. Tests passed. Then you noticed it — a column full of personal data slipped into a commit weeks ago and spread across the tree. Every checkout, every clone, every mirror now carried it.
This is the nightmare of sensitive columns in Git rebase workflows. And it’s more common than people admit.
Rebasing is supposed to make history linear, but when you rebase over commits that touched sensitive columns — names, emails, SSNs, tokens, anything you’d never want public — you’re rewriting a trail of potential leaks. Worse, rebasing can duplicate the problem when those commits get reshuffled and pushed upstream.
The problem starts where code meets data. Developers add migrations or sample dumps into version control. Maybe a quick debug dump ends up committed. Those columns ride along in SQL schema files, seed data, or even CSV snapshots for tests. The rebase doesn’t discriminate — it lifts everything and reapplies it commit by commit. Without intervention, sensitive data persists.
Best practices for Git rebase sensitive columns begin with prevention. Sensitive columns don’t belong in your tracked data sets. Migrations should define schema without live production data. Seed files should use anonymized or synthetic values. But prevention isn’t always enough. Mistakes happen.
If you’ve already rebased and pushed, history rewriting gets harder. git filter-repo or BFG Repo-Cleaner can surgically remove patterns or specific columns from history. Patterns should target both the data file structures and the actual data values. You must verify every rewritten commit, because leaving even a single occurrence means the leak remains. Then force push the cleaned branch, and coordinate with every collaborator to reset their local histories.
True security with Git and sensitive columns requires visibility. You can’t protect what you can’t see. Automated scanning for sensitive columns in schema changes and data files is critical. Static scanning in CI should block commits before they hit remote. Post-commit scanning can alert you before a rebase spreads bad data even further.
The cleaner and more trustworthy your Git history, the faster you ship without fear of hidden leaks. Reducing the blast radius of a slip-up is the difference between a quick fix and a painful incident review.
If you want to see this kind of protection happen without writing the scripts yourself, you can see it live in minutes with hoop.dev.