Copilot ya puede aprobar un pull request, pero la función viene desactivada
GitHub anunció el 1 de septiembre de 2026 que Copilot code review ya puede aprobar formalmente un pull request. La función está en vista previa pública para Copilot Pro, Pro+, Max, Business y Enterprise, pero llega desactivada por defecto, según el anuncio oficial de GitHub.
Cuando los administradores la habilitan, la aprobación de Copilot puede satisfacer la regla de aprobaciones requeridas de un repositorio. Sin esa autorización, el asistente deja una evaluación dentro de una revisión de tipo «Comment»: puede considerar que los cambios están listos, pero ese juicio no desbloquea la fusión.
Evaluar, comentar y aprobar son acciones distintas
La novedad exige separar lo que Copilot escribe de la acción formal que GitHub registra. Todas las revisiones de Copilot incluyen una evaluación en el comentario general, pero solo una revisión de tipo «Approve» puede contar como aprobación requerida.
- Evaluación de aprobación: expresa si Copilot considera que el pull request está listo. Es texto informativo dentro del comentario general y no satisface por sí solo ningún requisito de fusión.
- Revisión «Comment»: es el resultado predeterminado. Conserva los comentarios y sugerencias del asistente, pero no registra una aprobación ni una solicitud formal de cambios.
- Revisión «Approve»: es la aprobación formal que Copilot puede enviar únicamente cuando la función está autorizada. Para que satisfaga el requisito de fusión, el repositorio también debe permitir que las aprobaciones de Copilot se contabilicen.
La diferencia no depende del tono favorable del comentario, sino del tipo de revisión registrado y de la política del repositorio. La documentación operativa de GitHub confirma que el comportamiento predeterminado es «Comment», no «Approve» ni «Request changes».
La autorización se controla en tres niveles
La función no se activa desde una preferencia personal del autor del pull request. Empresa, organización y repositorio forman una cadena de control: un nivel superior puede impedir que el inferior conceda a Copilot la capacidad de aprobar.
- Empresa: sus administradores pueden dejar las aprobaciones deshabilitadas en todas partes, permitirlas solo en organizaciones seleccionadas o delegar la decisión a cada organización. «Disabled everywhere» es la política empresarial predeterminada.
- Organización: sus propietarios pueden contabilizar las aprobaciones en todos los repositorios, delegar la decisión, seleccionar repositorios concretos o impedirlas en toda la organización.
- Repositorio: sus administradores disponen de un control para permitir que Copilot envíe revisiones aprobatorias y otro para decidir si estas satisfacen los requisitos de fusión.
Esos dos controles del repositorio permiten un estado intermedio: Copilot puede registrar «Approve», pero su aprobación puede no contar para la regla de fusión. La configuración oficial de code review también permite limitar el efecto por rutas: admite hasta 15 patrones glob, uno por línea, y la aprobación solo cuenta si todos los archivos modificados coinciden con alguno de ellos.
Si el campo de rutas queda vacío, esa restricción no se aplica. Si un pull request modifica siquiera un archivo fuera de los patrones autorizados, la aprobación de Copilot no satisface el requisito, aunque los demás archivos sí pertenezcan al ámbito permitido.
Un commit posterior descarta la aprobación
Una aprobación válida no permanece asociada indefinidamente al pull request. Cuando se incorpora un commit después de que Copilot haya aprobado, GitHub descarta esa aprobación; una revisión independiente de QATechTools recoge la misma invalidación y la necesidad de solicitar una evaluación nueva.
Esto evita que la decisión sobre una versión anterior del código siga contando después de cambiar el contenido revisado. Sin embargo, descartar la aprobación y ejecutar otra revisión son acciones separadas: Copilot no vuelve a revisar automáticamente cada envío salvo que el repositorio tenga activada la revisión de nuevos pushes.
Cuando esa opción no está habilitada, el equipo debe volver a solicitar la revisión. La regla protege la vigencia de la aprobación, pero no garantiza que exista una nueva evaluación ni que intervenga una persona.
La aprobación de Copilot satisface una regla concreta
El alcance confirmado es la regla de aprobaciones requeridas del repositorio. Si la política permite contabilizar a Copilot, su «Approve» puede ocupar uno de los lugares exigidos antes de fusionar; una evaluación favorable escrita en «Comment» no puede hacerlo.
Eso tampoco demuestra que el pull request haya recibido revisión humana. Una organización que exija la intervención de una persona, un equipo determinado o un propietario del código necesita conservar esos controles por separado: la nueva función modifica cómo GitHub cuenta una aprobación autorizada, no redefine por sí sola las políticas internas.
La situación queda así mientras dure la vista previa pública: Copilot puede emitir una aprobación formal y hacer que cuente para la fusión, pero únicamente dentro de los permisos concedidos por empresa, organización y repositorio, y de las rutas autorizadas si se configuraron. La función sigue desactivada por defecto, y cualquier commit posterior invalida la aprobación anterior.
Lee también:
Suscríbete a nuestro boletín
Reciba las últimas noticias sobre Web3, IA y criptomonedas directamente en su bandeja de entrada.