GitHub Ties Every Commit to the Account That Pushed It

GitHub is adding a new piece of identity data to every commit: The authenticated account that pushed it.

The feature, called push attribution, entered limited public preview on October 12 for GitHub Enterprise customers. GitHub now records the user who pushed each commit and shows that pusher identity in the UI and the API, next to the existing author and committer fields. It also adds a repository rule that can block pushes when the committer doesn’t match the person doing the pushing.

It sounds like a small change. But it closes a gap that has existed since the beginning of Git.

The Problem With Author and Committer Fields

Git was built as a distributed system. Commits get created on a laptop, passed between collaborators, and pushed to a remote later. So the author and committer fields are just text the client supplies. Anyone can set user.name and user.email and claim to be anyone.

GitHub’s changelog spells out the risk. Anyone with write access to a repository can set those fields to any name and email. An attacker who compromises a low-privilege account can forge commits that look like they came from a trusted maintainer. That can slip past review policies and muddy audit trails.

GitHub has always authenticated pushes. It didn’t, however, keep a durable, per-commit record of who pushed. Once a commit landed, the only identity on display was the one the client claimed.

Signed commits help. A GPG, SSH, or S/MIME signature proves the key holder created the commit, and GitHub shows a Verified badge when the check passes. But signing is opt-in. Many teams don’t enforce it, and unsigned commits still display whatever name the author typed.

What Changes With Push Attribution

The preview adds two things.

First, every commit pushed to a repository gets an authenticated pusher identity. That identity sits apart from the author and committer metadata, and it shows up wherever commits are displayed. Reviewers and incident responders get one identity on each commit that the client didn’t make up. Instead of matching push events in audit logs to individual commits, they can see the pusher on the commit itself. GitHub says teams can use it to spot-check suspicious activity and speed up security investigations.

Second, there’s a new ruleset condition called “Committer must match pusher.” When enabled, it blocks any push where the committer metadata doesn’t match one of the authenticated pusher’s verified email addresses. Administrators add it through rulesets, the same mechanism already used to control who can push to a branch and how commits must be formatted.

The first piece makes spoofing visible. The second makes it harder to pull off in the first place.

“Commit authorship has been self-reported since Git began, and enterprise audit trails were built on it anyway,” said Mitch Ashley, vice president and practice lead for CIO & Technology Buyers and Software Lifecycle Engineering at The Futurum Group. “Push attribution puts one identity on each commit that the client cannot invent.”

Why It Matters Now

Software supply chain attacks often come down to trust. The 2024 backdoor in the xz Utils compression library showed how much damage follows when someone gains maintainer-level trust and abuses it. Push attribution wouldn’t stop a patient insider like that. But it does make it harder for someone with a stolen low-privilege token to impersonate the people a team trusts most.

AI coding agents add another layer. Bots, agents, and automation tokens now write and push more commits instead of people at keyboards. When something goes wrong, teams need to know which account actually put the code into the repository. A commit can carry a human’s name in the author field while an agent’s token did the push. Push attribution records that difference instead of hiding it.

What to Check Before Turning on the Rule

The pusher field is passive. The ruleset isn’t, and it could break some workflows.

Plenty of legitimate processes push commits that carry someone else’s committer email. A maintainer pushing a contributor’s branch. A release bot pushing commits made elsewhere. A migration that imports years-old history. Teams should inventory these patterns before enabling the rule broadly.

Ashley expects that inventory to reveal a lot. “Release bots, shared tokens, and agents running on borrowed credentials all surface at once,” he said. “The match rule is where teams find out how many workflows depend on one identity acting for another.”

His advice is to fix identity first. “Engineering leaders should give every agent its own accountable identity before enforcing the rule, or the bypass list becomes the new audit.”

The announcement also leaves open questions. It doesn’t yet explain how the rule treats bypass lists, bot identities, deploy keys, GitHub-generated commits, or commits with multiple authors. That’s normal for a limited preview. But it means teams should test in a few repositories before rolling it out.

Push attribution doesn’t replace existing controls either. Tight write-access management, required reviews, and commit signing still matter. A compromised account with legitimate access can still push malicious code under its own name. The difference is that the name will now be accurate.

Availability

Push attribution is available now as a limited public preview for GitHub Enterprise customers. Organizations that want in need to contact their GitHub account team. GitHub hasn’t said when the feature will reach general availability or whether it will come to other plans.

For DevOps teams, the takeaway is simple. Git’s author fields have always been a claim, not proof. GitHub now records the identity that actually pushed and lets admins require the two to match. It won’t stop every attack. But it takes an easy one off the table.