从 author/committer 到 pusher：commit 元数据模型的一次扩展

GitHub 在 2026 年 10 月 12 日发布 changelog，宣布 push attribution 进入有限公开预览。核心变化是：GitHub 现在为每个被推送到仓库的 commit 持久记录经过认证的推送者身份（authenticated pusher），并在 UI 和 API 中与既有的 author、committer 字段并列展示。

理解这次变化，需要先看清旧模型的边界。commit 的 author 和 committer 字段本质上只是推送客户端提供的字符串，任何拥有仓库写权限的人都可以把它们设置成任意姓名和邮箱。这意味着一个低权限账号被攻陷后，攻击者可以伪造出看起来来自可信维护者的 commit，从而绕过审查策略、混淆审计线索。GitHub 本身已经对 push 做认证，但此前这种认证结果并没有以 per-commit 的形式持久化下来。push attribution 补上的正是这一层：把认证结果与每个 commit 绑定。

机制：持久化推送者身份与规则条件

根据官方说明，本次发布包含两个可操作的能力。

第一，每个推送到仓库的 commit 现在都附带一个持久、经过认证的 pusher 身份，独立于 author 和 committer 元数据所声称的内容。也就是说，无论 commit 里的 author/committer 字符串写的是谁，pusher 字段记录的是实际通过认证执行推送的账号。

第二，新增仓库规则条件 Committer must match pusher。当启用该规则时，如果 committer 元数据与认证推送者的任一已验证邮箱地址不匹配，推送会被阻止。官方将其定位为关闭 commit 身份伪造路径的手段。

在可见性上，pusher 身份会出现在所有展示 commit 的位置，因此可以用它来抽查可疑活动或加速安全调查，而不必依赖未经验证的元数据。要启用更严格的身份要求，需要把 Committer must match pusher 规则加入 ruleset。

可用范围与前置条件

push attribution 目前以有限公开预览形式提供，面向 GitHub Enterprise 客户。希望加入预览的团队需要联系其客户团队申请访问权限。规则配置的细节可参考 GitHub 文档中关于 push rulesets 的说明。

这里有两个工程上必须注意的边界：其一，预览范围限定在 Enterprise，个人账号或非 Enterprise 组织当前不在范围内；其二，规则是 opt-in 的，pusher 身份被记录不等于 committer 会被强制校验，只有显式添加规则后才会阻断不匹配的推送。

对 CI/CD 审计与供应链安全的工程影响

从审计角度看，pusher 字段把“谁认证推送了这段代码”变成可查询的事实，而不是依赖 commit 内自报的字符串。对于需要回答“这个 commit 究竟由哪个账号推上来”的场景，这是一个更可靠的锚点。安全调查时可以先按 pusher 聚合异常推送，再对照 author/committer 是否被伪造。

从供应链安全角度看，Committer must match pusher 规则把身份一致性变成可强制执行的策略。它针对的是攻击者用低权限账号伪造高信任身份这一具体路径。需要明确的是，官方资料只说明该规则校验 committer 元数据是否匹配推送者的已验证邮箱，并未声称它能覆盖所有伪造或供应链攻击形态。

对 CI/CD 而言，一个直接的影响是：如果流水线或机器人账号在推送时设置的 committer 邮箱与其账号已验证邮箱不一致，启用该规则后推送会被拒绝。因此在启用规则前，需要先盘点自动化推送所使用的 committer 配置。

AI Agent 提交代码时的溯源问题

当 AI Agent 自动提交并推送代码时，author/committer 字符串同样可以被任意设置，可能写成人类维护者的名字，也可能写成某个工具名。push attribution 提供的是一个不同的维度：pusher 是实际通过认证执行推送的账号。

因此，区分人类与机器推送者，在工程上应依赖 pusher 身份所对应的账号类型与凭证，而不是 commit 里的 author/committer 文本。官方资料并未提供针对 AI Agent 的专门标记或分类字段，所以“如何识别机器推送者”需要结合账号体系与凭证管理自行设计，不能从本次发布中推导出额外的机器身份语义。

API 读取与迁移适配建议

以下为工程建议，非官方资料内容：

  1. 读取侧：在消费 commit 数据的工具中，把 pusher 作为独立字段纳入模型，不要把它与 author/committer 合并。审计与告警逻辑应优先基于 pusher 做聚合。
  2. 写入侧：检查所有自动化推送流程中 committer 的姓名与邮箱配置，确保其与推送账号的已验证邮箱一致，避免启用规则后推送被阻断。
  3. 灰度策略：先在非关键仓库的 ruleset 中启用 Committer must match pusher，观察被阻断的推送来源，再逐步推广。
  4. 权限与凭证：由于 pusher 反映的是认证账号，机器人账号的凭证管理直接影响溯源质量，应避免多用途共享账号。
  5. 预览准入：确认组织是否属于 Enterprise 并已申请预览，否则相关字段与规则可能不可用。

小结

push attribution 把 GitHub 已有的 push 认证结果下沉为 per-commit 的持久化 pusher 身份，并在 UI/API 中暴露，同时提供 Committer must match pusher 规则来阻断 committer 与推送者不匹配的推送。它改变的是 commit 身份的可信锚点：从客户端自报的字符串，转向经过认证的推送者。对 CI/CD 审计、供应链安全和自动化提交溯源而言，这是一个值得纳入数据模型与策略设计的结构性变化。