When a production bug appears after a deployment, one of the first things a developer checks is the Git history. The team looks at recent commits, reviews the changed files, and tries to understand who made the change.
Usually, this works well. But there is a problem: the name displayed on a Git commit does not necessarily tell you which account pushed it to the repository.
A commit can contain an author's name and email address supplied by the Git client. Someone with permission to push can set those values to a different identity. During a security investigation, relying only on this information can make it harder to understand how a change reached the repository.
GitHub's push attribution feature addresses this gap by recording the authenticated account that pushed a commit, separately from the author and committer information. The feature entered limited public preview for GitHub Enterprise customers in October 2026.
For developers and repository administrators, the practical benefit is straightforward: you can use commit attribution as an additional source of evidence when investigating unexpected changes, reviewing repository activity, or improving security controls.
Understanding GitHub Commit Attribution
Before investigating a commit, it helps to understand the three identities involved.
Identity | What it tells you | Where it is useful |
|---|
Author | Who is credited with writing the change | Understanding code contributions |
Committer | Who is recorded as creating the commit object | Investigating rebases and cherry-picks |
Pusher | Which authenticated account pushed the commit to GitHub | Reviewing repository activity and investigating suspicious pushes |
Consider a team maintaining an ASP.NET Core application. A developer fixes an authentication bug, another developer cherry-picks the fix into a release branch, and a release engineer pushes the updated branch.
The author may be the original developer, while the committer may reflect the person who created the cherry-picked commit. The pusher identifies the authenticated account responsible for uploading the commit.
These identities can legitimately differ. The important question is whether the difference matches the team's workflow.
Why author and committer information alone can be misleading
Git allows developers to configure their commit identity locally.
git config user.name "Application Maintainer"
git config user.email "[email protected]"
These commands configure the default name and email recorded in new commits. They do not verify that the person using the computer is actually the application maintainer.
A developer can also override the author information for a specific commit:
git commit --author="Application Maintainer <[email protected]>" \
-m "Update authentication configuration"
The resulting commit records the supplied author information. It does not prove that the maintainer wrote or approved the change.
This is why commit metadata should not be treated as authenticated identity evidence. Push attribution adds a separate record of the account GitHub authenticated when the commit was pushed.
Investigating a Suspicious Commit Step by Step
Suppose a team notices that a production configuration file has changed unexpectedly. The commit history shows the name of a trusted developer, but the developer does not recognize the change.
Instead of assuming the displayed identity is correct, follow a repeatable investigation process.
Step 1: Identify the exact commit
Open the repository's commit history and select the commit under investigation.
Record its commit SHA, message, target branch, and affected files. The SHA is particularly important because it identifies the exact commit being reviewed.
You can inspect a commit from your local repository with Git:
git show --no-ext-diff --stat <commit-sha>
Replace <commit-sha> with the actual commit identifier.
This command summarizes the files changed by the commit. It is a useful first step when the repository contains many files and you need to identify the scope of the change.
To inspect the actual patch, run:
git show --no-ext-diff <commit-sha>
Review the output carefully, especially changes to authentication, permissions, secrets handling, deployment configuration, and dependency versions.
Step 2: Compare the author and committer
Run the following command to inspect the recorded identities and timestamps:
git show -s --format=fuller <commit-sha>
The output includes the author, author date, committer, committer date, and commit message.
Check whether the identities make sense for the way the change was created.
For example, a different committer may be expected when a developer cherry-picks a fix into a maintenance branch. A mismatch is a reason to investigate, not automatic proof of an attack.
Step 3: Verify the pusher in GitHub
When push attribution is available for the repository, open the commit in GitHub and inspect the pusher identity shown alongside the author and committer.
Compare that identity with the expected developer, release engineer, or automation account.
If the pusher is unfamiliar, investigate the surrounding repository activity. Check the related pull request, available audit records, branch protection settings, and the account's permissions.
The distinction matters because a trusted-looking author name can be supplied by the client, whereas push attribution records the authenticated identity associated with the push.
Availability note: GitHub's push attribution feature is in limited public preview for GitHub Enterprise customers. If the pusher identity is not visible in your environment, first confirm that your organization has access to the preview. Do not assume that a missing field means the push was anonymous.
Step 4: Connect the commit to the review process
After checking the identities, determine how the change reached the branch.
Look for the associated pull request, review approvals, status checks, and merge activity. If the commit was pushed directly, establish whether that was permitted by the repository's policies.
For example, a change to an authentication middleware file may have been pushed by a legitimate release account but bypassed the expected review process. The pusher identity helps establish which account uploaded the commit; the review history helps establish whether the change followed the required process.
These are different questions, and both matter.
Step 5: Preserve the evidence
If the change remains suspicious, record the commit SHA, pusher identity, affected files, relevant timestamps, and the findings from the review.
Avoid rewriting Git history or changing the commit metadata just to make the identities appear consistent. Preserve the original evidence until the investigation is complete.
If the investigation confirms unauthorized activity, follow the organization's incident response process to review account access, revoke compromised credentials where appropriate, and assess the affected code.
Searching Commit History Efficiently
A repository may contain thousands of commits. GitHub's commit search can narrow the investigation by author, committer, date, or commit message.
For example, the following searches help locate commits associated with a particular identity:
author:USERNAME
committer:USERNAME
author-email:[email protected]
committer-email:[email protected]
Replace the example values with the identity you want to investigate.
You can also search for commits containing a relevant term in their messages or narrow the search to a particular repository.
These filters are useful for finding potentially related changes, but they search the author or committer information represented by those fields. They should not be treated as substitutes for checking the authenticated pusher identity.
For a local repository, Git can also filter the history by recorded author or committer:
git log --all --author="[email protected]" \
--format="%H %an <%ae> %ad %s" --date=short
This displays matching commit hashes, author names, author email addresses, dates, and commit messages across local branches. It does not identify the GitHub pusher.
Enforcing Identity Rules with GitHub Rulesets
Investigating suspicious activity after it happens is useful, but organizations may also want to prevent certain identity mismatches from being pushed in the first place.
GitHub has introduced a ruleset condition called Committer must match pusher. When available and enabled, this condition blocks pushes where the recorded committer metadata does not match a verified email address associated with the authenticated pusher.
Before enabling this rule, review how your team creates and delivers commits.
Identify the developers and automation accounts that push to protected branches.
Review verified email addresses associated with the relevant GitHub accounts.
Test ordinary commits, cherry-picks, backports, and automated releases.
Investigate legitimate identity mismatches in a test repository.
Enable the rule after confirming that the intended workflows work correctly.
This rule does not mean every author must be the same as the pusher. It specifically checks the relationship between the committer metadata and the authenticated pusher under the rule's requirements.
It also does not replace code review or signed-commit policies. Identity matching and code integrity are related but separate controls.
Advantages and Disadvantages
Advantages
More useful audit trails: Investigators can distinguish the account that pushed a commit from the author and committer recorded in Git.
Faster investigation: The pusher identity provides another data point when an unexpected change appears in a repository.
Better identity enforcement: Supported rulesets can prevent certain mismatches between committer metadata and the authenticated pusher.
Clearer workflow reviews: Teams can compare the recorded identities with their expected release and automation processes.
Disadvantages
Limited availability: Push attribution is not necessarily available to every GitHub account or repository.
Workflow compatibility concerns: Cherry-picks, backports, and automated commit creation may need testing before stricter rules are enabled.
No guarantee of safe code: An authenticated pusher can still upload a vulnerable or incorrect change.
Additional investigation work: Teams must correlate identity information with pull requests, permissions, diffs, and other records to understand the full event.
Best Practices for Production Repositories
Review the actual diff. Never decide whether a commit is safe based only on the identities shown in the history.
Keep branch protection enabled. Require appropriate reviews and automated checks for important branches.
Use dedicated automation identities. Document which pipelines can push commits and restrict their permissions.
Test identity rules before rollout. Verify legitimate release workflows before enforcing stricter matching requirements.
Preserve investigation evidence. Record the commit SHA and relevant repository activity before modifying the branch or its configuration.
Treat mismatches as signals, not conclusions. Establish whether the activity is legitimate before taking action against an account.
Common Troubleshooting Scenarios
Problem | What to investigate |
|---|
The author is familiar, but the change is unexpected | Inspect the pusher identity, commit diff, and associated review history |
Author and committer identities differ | Check whether the commit was cherry-picked, rebased, or recreated |
Pusher information is unavailable | Confirm preview eligibility and feature availability |
A push is rejected by the committer-matching rule | Check the committer metadata and the pusher's verified email addresses |
An automated release fails after enforcement | Review the automation identity and how the pipeline creates commits |
A suspicious commit has no associated pull request | Check direct-push permissions and available repository audit records |
Summary
GitHub commit attribution makes repository investigations more reliable by separating the author and committer recorded in a commit from the authenticated account that pushed it.
For developers, the practical workflow is to identify the commit, inspect its metadata, verify the pusher where the feature is available, review the actual diff, and connect the change to the repository's approval process.
For administrators, push attribution and the Committer must match pusher ruleset condition provide additional tools for strengthening repository identity controls. They should be introduced alongside branch protection, code review, and appropriate access management.
The main lesson is simple: a name displayed in Git history is not enough to explain how a change reached a repository. Investigating the identities, the code, and the surrounding activity together provides a much clearer picture of what happened.
Join the conversation! Your thoughts help the community grow.