What if real customer data was committed to a test fixture in git?

Treat it as a data exposure. Confirm what was committed and who can read the repository, remove the file from history with a rewrite tool, clean every clone and cached copy, rotate any credentials in it, and record what happened. Then replace the fixture with synthetic data and add a guard. Ask your privacy lead whether notification is required.

Why git makes this harder

Deleting a file in a new commit removes it from the current tree, not from history. Anyone who cloned the repository, forked it, or opened an old commit can still see it. GitHub's own guidance on removing sensitive data says that if the content is a secret such as a password or token, the first step is to revoke or rotate it, and that once rotated, it can no longer be used for access, which may be sufficient for that case.

Personal data cannot be rotated, so history rewriting and copy cleanup matter more.

First hour

1. Stop the spread. Restrict the repository, pause forks and mirrors if you can, and ask people not to pull further changes until you say so.
2. Identify the data. Find the commit, file and records. Note how many people are affected, what fields are present, and whether any credentials or tokens are included.
3. Find the audience. List who had read access since the commit, including contractors, CI systems, integrations and any public exposure. Public repositories raise the severity sharply.
4. Tell the right people. Bring in your privacy or security lead now. Whether this triggers notification duties depends on your jurisdiction and facts, and that decision is theirs, not an engineer's.

Remove it from history

5. Rewrite history. Use a dedicated tool such as git filter-repo to strip the file from every commit. GitHub's documentation describes this approach and warns about consequences. For example, commit hashes change, and signatures on commits and tags are removed by many history rewriting tools, so plan for that.
6. Force push and clean the host. After pushing the rewritten history, GitHub notes you can remove cached views and references in pull requests only by contacting support, so file that request if the repository is hosted there.
7. Clean the clones. Every colleague's clone and every CI cache still holds the old objects. The filter-repo manual has instructions for cleaning other copies, and GitHub points to them. Ask each person to re-clone rather than pull.
8. Check forks and mirrors. Forks keep the old history. Ask owners of forks to delete them, or delete them if they are yours.
9. Rotate credentials that appeared in the data, even if you think nobody saw them.

Replace and prevent

10. Swap in synthetic data. Generate a fixture with a seeded generator and reserved example domains, as described in the related posts on seed scripts and safe email domains.
11. Add a guard. Add a CI check that fails when fixtures contain emails on non reserved domains, long digit strings or other patterns that look like personal data. Keep the patterns specific to your data.
12. Add a pull request template line asking whether test data came from production.
13. Write it up. Record timeline, scope, actions and who decided on notification. A short, factual note helps a later review.

Mistakes to avoid

• Deleting the file in a normal commit and calling it done.
• Rewriting history without telling the team, which creates confusing merge conflicts and resurrects the data when someone pushes an old branch.
• Forgetting build artifacts and package caches that included the fixture.
• Guessing about legal duties instead of asking the right person.

Try it yourself

Click through it at your own pace, or open it full screen. Click through the gate to see how a check on a pull request can stop a change before it merges, and think about where a fixture check would sit.

Quick check

Sources

• GitHub Docs, removing sensitive data from a repository
• GDPR Article 5, principles

Last reviewed: 19 October 2026.