GitHub push attribution preview: record author, committer and pusher separately
A familiar name on a commit does not establish who sent that commit to the server. On October 12, GitHub announced a limited public preview of durable, authenticated pusher attribution per commit. The useful operational change is that client-supplied author and committer metadata can be considered separately from the identity GitHub authenticated for the push.
What the new evidence answers
Author and committer metadata describe authorship and commit creation, but their name and email strings come from the client. The pusher record adds an authenticated transfer identity. Teams can use that distinction to investigate a suspicious delivery without assuming that a trusted-looking name proves who performed it. The record answers a different question from whether the patch was reviewed.
Check preview access first
The announcement limits availability to GitHub Enterprise customers in the public preview; interested customers are directed to their account team for access. This is not a general rollout to every account. If an operating repository does not expose the feature, check participation and availability before labeling the missing interface a permissions defect or promising an implementation date.
Observation and enforcement are separate decisions
The new Committer must match pusher condition blocks a push when committer metadata does not match a verified email of the authenticated pusher. Viewing attribution and enabling that rule are separate decisions. Neither substitutes for reviewing the diff or checking a signature. An authenticated account can still deliver an incorrect change; the identity evidence does not establish code safety.
Start with your automation flow
If one account creates commits and another pushes them, document both before changing a ruleset. Our operational suggestion is to test accepted and mismatched deliveries in a test repository and decide who reviews the evidence. Do not hide failures by indiscriminately rewriting names or disabling protection. Establish which identity is intended at each step, then compare it with the observed behavior.
A small team can begin by linking the commit hash, observed transfer identity and check time to the review record. Keep approval and diff evidence separately: an identity match does not mean that a human inspected the patch. This makes later investigations less dependent on interpreting display names from memory.
The recurring engineering question is whether a displayed author name is identity evidence. We have not treated unverified community anecdotes or invented adoption metrics as facts. Recheck preview participation and the current UI/API in the actual account before relying on the feature in production.
Official sources
Announcement scope checked October 13, 2026; operational suggestions are identified separately.