GitHub推送归属进入公开预览，认证推送者与提交者如何区分

如果团队一直把 Git 提交里的 committer 当成“真正推送代码的人”，这次 GitHub 的新公告值得认真看一下。2026 年 10 月 12 日，GitHub 宣布 Push attribution for commits 进入 limited public preview：平台会把经认证的推送者（pusher）作为独立身份持久记录，并与原有的 author、committer 字段一起展示。

官方地址：https://github.blog/changelog/2026-10-12-push-attribution-public-preview/

一句话理解：author 和 committer 仍然是提交客户端提供的元数据，pusher 则是 GitHub 认证过的实际推送身份。新能力解决的是“谁把这个提交推入仓库”的审计问题，目前不是所有账号都能立即使用。

先把 author、committer 与 pusher 分开

Git 提交通常会带有 author 和 committer 信息，它们本质上是字符串，推送客户端可以提交自定义的姓名与邮箱。因此，拥有仓库写权限的人可以让这两个字段看起来像某位维护者，字段本身并不能证明这次推送由谁完成。

GitHub 这次加入的 pusher 是另一条身份线：它来自已经通过 GitHub 认证的用户，并且会按提交持久记录。排查审计线索时，不能用 pusher 去覆盖或改写 author、committer，而应当把三者并列阅读。

这次公开预览实际增加了什么

公告给出的重点不是新增一种提交格式，而是为每个推送到仓库的提交附加可验证的 pusher 身份。这个身份会出现在提交相关的 GitHub 界面和 API 中，并与已有 author、committer 信息同时保留。

因此，安全调查可以先看 pusher，再对照提交中的 author 和 committer：如果三者不符合团队预期，pusher 能帮助快速定位“哪个已认证账号把提交送进来”，而不是只根据可伪造的姓名和邮箱判断来源。

Committer must match pusher 规则限制什么

GitHub 同时新增了一个仓库规则条件：Committer must match pusher。启用后，如果提交里的 committer 元数据无法匹配经认证推送者的任一 verified email，推送就会被阻止。

这个规则针对的是提交者身份冒用路径，不等于要求 author 和 committer 必须永远相同，也不等于所有历史提交都会被自动重写。它更适合放进需要较强身份一致性的仓库 ruleset，由维护者根据机器人账号、镜像同步和自动化发布的实际模型评估影响。

现在能不能直接在所有仓库启用

不能按“已经正式全量上线”来理解。GitHub 公告写明，Push attribution 当前是 GitHub Enterprise customers 的 limited public preview。对感兴趣的团队，官方建议联系自己的 account team 申请加入预览。

也就是说，普通账号或尚未获得预览权限的组织，不应据此假设界面、API 字段或 ruleset 条件已经可见。文章只确认公告列出的范围，不把预览能力扩展解释为所有计划的现成特性。

团队可以先做的三项准备

第一，审计近期敏感提交时，把 author、committer 和 pusher 分开记录，避免只看提交页面上的姓名。第二，梳理机器人、镜像和发布账号使用的 verified email，提前识别启用匹配规则后可能受到影响的自动化。第三，如果组织属于 GitHub Enterprise 并有预览需求，直接向 account team 询问资格与开通方式。

这三步不依赖猜测尚未公布的功能，也不会把公开预览误当成已经完成普及的安全开关。

相关问题

author 和 committer 以后会被 pusher 取代吗？

不会。公告描述的是在原有 author、committer 字段旁边增加独立的认证 pusher 身份，三者承担的语义不同。

Committer must match pusher 会检查 author 吗？

公告明确描述的是 committer 元数据与认证 pusher 的 verified email 匹配条件，不能把它扩大解读为对 author 的同样限制。

普通 GitHub 账号何时能使用？

当前公告只说明 GitHub Enterprise customers 的 limited public preview，并要求有兴趣的客户联系 account team；没有公布面向所有账号的正式开放时间。