Git commit author names and emails: personal data in code history

Are git commit author names and emails personal data?#

Git commit author names and emails are personal data in most privacy frameworks because they identify an individual engineer. Each commit records an author and a committer, each with a name, an email address and a timestamp that includes a time zone offset.

Early commits often carry personal Gmail or university addresses from before company accounts existed. Contractors may appear under agency domains, and some engineers appear under several identities as laptops and accounts changed. All of those point to real people, including people who left long ago.

Whether a specific law applies, such as GDPR for engineers based in the EU, is a question for counsel. The practical point for a CTO is simpler: a code history delivered with raw identities shares a detailed activity record for every engineer who ever committed.

Where identities hide in a repository#

Identities hide well beyond the author field, so a rewrite that changes only author and committer leaves names behind. Check each location below before choosing a method.

Commit messages also mention customers and paste ticket text, so scan them for customer names in the same pass.

Mailmap pseudonymization vs a history rewrite#

A .mailmap file maps old names and emails to a canonical identity when git displays history, while a history rewrite replaces the stored values in a new copy of the repository. Only the rewrite removes identities from what you deliver.

The common working pattern combines both. Use a mailmap to consolidate each engineer's aliases into one identity, then run a rewrite with a tool such as git filter-repo on a mirror clone. The live repository and its commit hashes stay untouched.

Why consistent IDs keep authorship patterns#

Consistent pseudonymous IDs preserve authorship patterns, such as who owned which module, who reviewed whose changes and how expertise moved through a codebase. Those patterns are part of why engineering histories interest AI developers, so destroying them lowers the value of the package.

A random replacement on every commit breaks every pattern. A stable ID per person, generated from a keyed hash or a lookup table, keeps the patterns while hiding the person. Resolve duplicates first, so one engineer with several email addresses becomes one ID rather than a handful of apparent strangers.

Label bots and service accounts separately, such as dependency update bots and CI users. Their commits are useful context, and counting them as people distorts the picture of human work.

A rewrite procedure for a delivery copy#

A rewrite procedure for a delivery copy should run in an isolated workspace and end with a search proving no original identities remain. Write the steps down so the same method applies to every repository in scope.

For secrets, open-source scanners such as Gitleaks and TruffleHog search git history for passwords, API keys and tokens. Gitleaks' README was updated in May 2026 to say the project is feature complete and future releases will be security patches only, which is worth weighing when you choose a tool to rely on.

• 1Make a mirror clone of each repository into a restricted workspace.
• 2List every distinct author, committer and tagger identity across the full history.
• 3Merge aliases into one identity per person with a mailmap file.
• 4Assign each person a stable ID and a role tag, such as employee, contractor or bot.
• 5Rewrite author, committer, tagger and trailer values with the same mapping across all repositories.
• 6Scan code, comments and messages for remaining names, emails and customer references.
• 7Run a secret scanner over the full history and rotate anything it finds.
• 8Search the rewritten copy for every original email address and confirm none remain.
• 9Store the mapping table separately under restricted access and never deliver it.

Illustrative: a vertical SaaS company prepares its GitLab history#

Illustrative: a fictional software company serving freight brokers runs a self-managed GitLab instance with many years of history across its core application, carrier integrations and infrastructure code. Early commits used the founders' personal email addresses, and contractors from several agencies appear under agency domains.

The CTO's team merged aliases with a mailmap, assigned stable IDs with role tags and rewrote a mirror copy, including Signed-off-by trailers and release tags. Branch names containing first names were dropped, and the AUTHORS file was excluded. Jira issues that cited old commit hashes were linked to the new hashes through a private lookup table.

The delivered history still showed which engineers owned the billing module and how reviews flowed between teams, without naming anyone. A search for every original email in the rewritten copy came back empty, and that result went into the preparation record.

How SourceX approaches code history#

SourceX handles identity rewriting in the Preparation step of the SourceX five-step transaction, after the Rights step has confirmed that the company owns the code, that contractors assigned their work, and that customer-owned or third-party code is carved out. The supplier approves the mapping method and reviews the verification result before Approval.

The method, scan results and exclusions are recorded in the privacy record of the SourceX Evidence Packet, while the mapping table stays with the supplier.