GitHub adiciona uma terceira identidade aos commits: quem realmente fez o push

O GitHub passou a registrar de forma permanente o usuário autenticado que executou o push e a exibir essa identidade na interface e na API, ao lado dos campos author e committer que já existiam. O recurso se chama push attribution e, por enquanto, está disponível em limited public preview. O anúncio foi publicado em 12 de outubro de 2026 no GitHub Changelog. Agora cada commit tem três identidades em vez de duas, e uma delas é confirmada pela plataforma.

O que mudou, exatamente

No git, os campos author e committer são preenchidos no lado do cliente. Seus valores vêm da configuração local ou de variáveis de ambiente, e nada impede de colocar neles o nome e o e-mail de outra pessoa. O GitHub associa esses endereços a contas e pode marcar o commit como Verified se ele estiver assinado, mas está longe de ser todo commit que tem assinatura. Já a informação de "quem enviou isso ao repositório" só podia ser reconstruída de forma indireta no histórico público, por exemplo por meio de eventos do repositório ou de logs de auditoria.

O push attribution fecha essa lacuna. A plataforma sabe quem se autenticou no momento do push e agora guarda essa informação como parte dos dados do commit. O campo pusher aparece na interface e está disponível pela API.

Por que isso importa na era dos agentes

O anúncio não detalha a motivação, então o que segue é a lógica de engenharia, e não declarações do GitHub. Hoje, um commit típico passa por várias mãos. O autor pode ser um desenvolvedor, o committer muda em um rebase, squash ou cherry-pick, e quem faz o push de tudo isso é um token de serviço ou um agente de IA que age em nome de um usuário. Os três campos dão três respostas diferentes à pergunta "de quem é este código".

Para investigar incidentes e fazer verificações de segurança, a diferença é fundamental. Se um commit malicioso, ou simplesmente quebrado, chegou a uma branch, o autor nos metadados não prova nada. O pusher mostra quais credenciais foram usadas para entregar o código. Para organizações com requisitos de compliance, é também uma forma de distinguir o trabalho de uma pessoa do trabalho da automação sem conferir logs manualmente.

O que se sabe e o que não se sabe

• Status: limited public preview, anunciado em 12 de outubro de 2026
• Novo valor: pusher, ou seja, o usuário autenticado que executou o push
• Onde aparece: interface do GitHub e API, ao lado de author e committer
• Fonte dos dados: autenticação no servidor, e não o git config do cliente
• Não divulgado no anúncio: preços, lista de contas e organizações com acesso, comportamento em commits antigos, formato exato do campo nas APIs REST e GraphQL, representação de GitHub Apps e bots

O último ponto é o mais interessante. O valor prático do recurso para quem constrói automações em torno de repositórios depende justamente de como o campo vai exibir aplicativos e agentes.

O que as equipes podem verificar desde já

Enquanto o recurso está em preview, ainda é cedo para incluí-lo em processos críticos, mas dá para se preparar. Primeiro, descubra se o preview está disponível para a sua organização e teste-o em um repositório não essencial. Segundo, verifique quais integrações fazem push no seu código: tokens pessoais, GitHub Apps, runners de CI, agentes.

É disso que depende o que você verá no campo pusher. Terceiro, se você tem scripts de auditoria que hoje montam o "quem enviou" a partir de eventos e logs, avalie se dá para substituí-los por consultas à API quando o formato do campo estiver estável. E, por fim, não abra mão da assinatura de commits: o pusher indica quem entregou o código, mas não prova quem o escreveu.