You run git log and there it is—your personal address, customer data, or an internal identity that should have stayed inside the firewall. The problem runs deeper than a stray config. Git keeps history forever, and rebasing won’t save you unless you know exactly how to rewrite it.
Masking email addresses in Git logs isn’t about vanity. It’s about control. Compliance rules, privacy laws, and security audits all care about what’s in the commit metadata. The moment a repo is cloned, that data is everywhere. You can’t just delete it; you must surgically rewrite history so it looks like it never existed.
Start by checking what’s exposed:
git log --pretty=format:'%ae'
That output is the truth. Every %ae is an author email burned into history. If the wrong ones show up, you need a rewrite. For branches still in flux, git rebase --interactive lets you edit commits and change author data.
When the damage runs into past months or years, you use git filter-branch (deprecated but still known) or the faster, safer git filter-repo tool:
git filter-repo --mailmap my-mailmap.file
The mailmap defines what to replace, mapping old emails to the safe ones you want in every commit. Push with force, and the rewritten repo starts fresh.
But here’s the catch. Old clones still hold the original addresses. Masking works when you control all the remotes and all the clones—or when your process ensures no sensitive data gets committed in the first place. Teams that scan commits in real time and enforce safe metadata policies never face these midnight rewrites.
Git rebase and email masking go hand in hand when the goal is a clean, compliant history that satisfies audits and keeps private identities off the public internet. It’s not magic. It’s discipline, automation, and the right tools in the right pipeline.
If you want to see this kind of safety net working right now, live, in minutes, check out hoop.dev. It’s where clean histories, masked identities, and zero-leak commits aren’t afterthoughts—they’re the default.