GitHub añade una tercera identidad a los commits: quién hizo el push

GitHub ha empezado a registrar de forma permanente al usuario autenticado que realizó un push y a mostrar esa identidad en la interfaz y la API, junto a los campos ya existentes author y committer. La función se llama push attribution y por ahora está disponible en limited public preview. El anuncio se publicó el 12 de octubre de 2026 en el GitHub Changelog. A partir de ahora, cada commit tiene tres identidades en lugar de dos, y una de ellas está confirmada por la plataforma.

Qué ha cambiado exactamente

En git, los campos author y committer se rellenan en el lado del cliente. Sus valores salen de la configuración local o de las variables de entorno, y nada impide poner en ellos el nombre y el correo de otra persona. GitHub asocia esas direcciones con cuentas y puede marcar un commit como Verified si está firmado, pero ni de lejos todos los commits llevan firma. Hasta ahora, quién había enviado algo al repositorio solo podía reconstruirse de forma indirecta en el historial público, por ejemplo a través de los eventos del repositorio o de los registros de auditoría.

Push attribution cubre ese vacío. La plataforma sabe quién se autenticó al hacer el push y ahora guarda esa información como parte de los datos del commit. El campo pusher se muestra en la interfaz y está disponible a través de la API.

Para qué sirve en la era de los agentes

El anuncio no detalla la motivación, así que lo que sigue es lógica de ingeniería, no declaraciones de GitHub. Hoy un commit típico pasa por varias manos. El autor puede ser un desarrollador, el committer cambia con un rebase, un squash o un cherry-pick, y el push lo hace un token de servicio o un agente de IA que actúa en nombre de un usuario. Los tres campos dan tres respuestas distintas a la pregunta «¿de quién es este código?».

Para investigar incidentes y en las revisiones de seguridad, la diferencia es fundamental. Si un commit malicioso, o simplemente defectuoso, llega a una rama, el autor que figura en los metadatos no demuestra nada. Pusher indica con qué credenciales se entregó. Para las organizaciones con requisitos de cumplimiento normativo, es además una manera de distinguir el trabajo de una persona del de la automatización sin cotejar registros a mano.

Qué se sabe y qué no

• Estado: limited public preview, anunciada el 12 de octubre de 2026
• Nuevo valor: pusher, es decir, el usuario autenticado que realizó el push
• Dónde se ve: interfaz de GitHub y API, junto a author y committer
• Fuente de los datos: autenticación en el servidor, no el git config del cliente
• No se revela en el anuncio: precios, lista de cuentas y organizaciones con acceso, comportamiento con commits antiguos, formato exacto del campo en REST y GraphQL, y cómo se representarán las GitHub Apps y los bots

El último punto es el más interesante. El valor práctico de la función para quienes construyen automatización en torno a los repositorios dependerá de cómo muestre el campo las aplicaciones y los agentes.

Qué conviene revisar ya

Mientras la función siga en preview, es pronto para incorporarla a procesos críticos, pero sí se puede ir preparando el terreno. Primero, averigüe si la vista previa está disponible para su organización y pruébela en un repositorio no clave. Segundo, revise qué integraciones hacen push a su código: tokens personales, GitHub Apps, runners de CI, agentes.

De ello depende lo que verá en el campo pusher. Tercero, si tiene scripts de auditoría que hoy reconstruyen «quién lo subió» a partir de eventos y registros, evalúe si podrá sustituirlos por consultas a la API cuando el formato del campo sea estable. Y, por último, no renuncie a la firma de commits: pusher indica quién entregó el código, pero no demuestra quién lo escribió.