GitHub has announced a limited public preview of push attribution for commits. The feature associates each pushed commit with the authenticated user who performed the push, independently of the author and committer information recorded in the commit.
The change is aimed at GitHub Enterprise customers that need stronger audit trails or more reliable identity signals for repository governance. It may help administrators distinguish who created or recorded commit metadata from the account that actually pushed the commit, but the feature is not generally available and several implementation details remain undocumented.
What changed with commit push attribution
Git commits already include author and committer metadata. GitHub says those values are client-supplied and can be changed by users with write access. Push attribution adds a separate, durable association with the authenticated pusher—the user who performed the push through GitHub.
GitHub says pusher attribution will appear alongside existing author and committer information in its user interface and API. The supplied announcement does not specify the exact field names, response formats, endpoint coverage, webhook representation, or audit-log format, so teams should not build integrations around assumed API properties.
These three identities represent different questions:
- Author: the identity recorded as having originally written the change.
- Committer: the identity recorded as having created or finalized the commit.
- Pusher: the authenticated GitHub user who sent the commit to the repository.
Keeping those identities separate can give investigators more context when commit metadata does not match the account that delivered the change. It can also help compliance and repository-management systems model commit activity without treating self-reported author or committer strings as the only identity evidence.
A new repository-rule condition
The preview also introduces a repository-rule condition called “Committer must match pusher.” According to GitHub’s announcement, the condition blocks pushes when the committer metadata does not match a verified email address associated with the authenticated pusher.
This is an enforcement option for a repository ruleset, rather than a claim that every commit will automatically satisfy the same identity relationship. Administrators must have preview access and add the announced condition to an applicable ruleset before relying on it to restrict pushes.
GitHub’s general ruleset documentation describes rulesets as collections of repository conditions, rules, enforcement settings, and bypass actors. Rulesets can generally target branches, tags, or pushes. The REST documentation also represents rulesets through fields for their targets, conditions, rules, enforcement, and bypass actors.
However, the supplied REST documentation does not document the new committer-matching rule type or its request payload. It also does not establish the precise address-selection or comparison algorithm. GitHub’s email API can expose multiple email addresses for the authenticated user and indicates whether each address is verified, primary, and public or private. That adjacent API information does not, by itself, document how the preview condition chooses or compares addresses.
Who can use the preview
Push attribution is available in a limited public preview for GitHub Enterprise customers. Interested customers must contact their GitHub account team and request access.
The announcement and supplied documentation do not identify which Enterprise products or deployment types are eligible. They also do not establish eligibility by region, organization, repository type, or account. General ruleset plan availability should therefore not be treated as proof that a particular organization can use the push-attribution preview.
Once access is confirmed, administrators can review the general ruleset workflow through repository Settings > Rulesets > New ruleset. The documented process applies to rulesets generally and is available to repository administrators or users with a custom role that includes the edit repository rules permission. The exact control or configuration sequence for “Committer must match pusher” has not been supplied.
Why the distinction matters for engineering teams
For development teams, the most important change is the ability to treat pusher identity as a separate data point. A commit may name one person as author, another as committer, and identify a third authenticated account as the pusher. That distinction can be useful when reviewing unexpected changes, investigating suspicious repository activity, or reconciling source-control events with internal access records.
Administrators may also use the new condition to reduce reliance on committer metadata that can be edited on the client side. The condition could support a policy that requires the recorded committer identity to correspond to a verified address held by the account pushing the change.
That does not make pusher attribution a complete security guarantee. The supplied material does not provide a full threat model, and it does not explain how the feature handles every automated or unusual workflow. Organizations should continue to treat author, committer, and pusher as distinct identity concepts rather than assuming that one field proves who performed every step in the development process.
What you should do
- Contact your GitHub account team if your organization is interested in participating in the limited preview.
- Confirm product and repository eligibility before planning a rollout. The available announcement does not list all eligible Enterprise deployment types or account configurations.
- Map your audit data model so author, committer, and pusher are stored as separate identities where the feature’s data is available.
- Review existing rulesets and identify repositories where a committer-to-pusher policy would support your governance requirements. Do not assume the condition’s API type or payload from the general ruleset API.
- Test operational workflows carefully after access is granted, especially any automated tooling or nonstandard push process. The supplied documentation does not establish behavior for bots, GitHub Apps, mirrors, force pushes, rewritten history, bulk pushes, or bypassed pushes.
- Update compliance and security tooling only from documented fields. Exact API names, endpoint coverage, historical attribution, retention, and webhook or audit-log behavior remain undocumented in the available material.
Preview limitations to keep in mind
The feature is not documented as retroactively adding attribution to existing commits, and the supplied sources do not explain retention or historical coverage. They also do not define how the condition behaves in every ruleset enforcement mode. General ruleset documentation describes Active and Disabled statuses and documents Evaluate for metadata restrictions, but it does not establish the new pusher condition’s behavior in each mode.
General rulesets can also define bypass access for eligible roles, teams, GitHub Apps, and Dependabot. The available material does not establish whether the new condition has special bypass behavior or how bypassed pushes are represented in attribution data.
For now, the practical approach is to treat push attribution as a preview capability that can improve identity context, not as a fully documented replacement for existing audit controls. Confirm access with GitHub, validate the behavior in your own repositories, and avoid assuming undocumented API or workflow semantics.
