Pull requests apilados en GitHub: revisiones más pequeñas, un solo merge

Abre un pull request con 1.500 líneas cambiadas y mira lo que le pasa. Quien revisa lee los primeros archivos con cuidado, luego el diff sigue, la atención se agota y el resto recibe un scroll y una aprobación. Nadie está siendo vago. Un diff grande pide más concentración de la que cabe en una sentada. El 6 de octubre de 2026 GitHub lanzó en disponibilidad general los pull requests apilados (stacked pull requests), y son su respuesta exactamente a esto: dividir un cambio grande en una cadena de pull requests pequeños que se revisan cada uno por su cuenta y aun así se integran juntos.

Por qué un pull request grande acaba aprobado sin más

Como regla general, la atención de quien revisa baja a medida que crece el diff. El primer archivo recibe preguntas de verdad. En el decimocuarto, solo se comprueba que el código parece código. El bug que importa rara vez está en el archivo que el equipo veía como arriesgado; está en un cambio pequeño a un helper compartido, a mitad de camino, donde ya nadie miraba. El autor también paga: una descripción para 1.500 líneas cuesta escribirla, así que suele decir «ver el diff».

La solución obvia, pull requests más pequeños, siempre ha tenido un coste. Si la segunda pieza depende de la primera, o esperas a que se integre la primera antes de abrir la segunda, o las abres como cadena y mantienes esa cadena a mano.

Qué es una pila y qué cambió con la GA

Una pila es una cadena de ramas en la que cada una parte de la anterior, y cada rama tiene su propio pull request. La primera añade una migración, la segunda el servicio que usa la nueva columna, la tercera el endpoint que llama al servicio. Cada una se revisa de forma independiente y la cadena se integra junta.

El problema nunca fue la idea. Era lo que pasaba cuando alguien pedía un cambio en el primer pull request cuando el segundo y el tercero ya estaban revisados: había que hacer rebase a mano de cada rama superior, y en los repositorios que descartan aprobaciones obsoletas, las revisiones de arriba también se perdían. La versión GA de GitHub va directa a eso. Su acción «Rebase stack» mantiene las aprobaciones del código que no cambió, incluso en repositorios que descartan aprobaciones obsoletas. Los commits rebasados siguen firmados, porque GitHub crea commits de reemplazo firmados y conserva al autor original.

El resto de la versión trata de cómo aterriza la pila. Entra y sale por la merge queue como un único grupo de merge, y con la opción de merge commit GitHub crea un merge commit por pull request. Los permisos de bypass se aplican al pull request sin integrar más bajo de la pila. Si una pila se ramifica y se borra su rama base, los pull requests de encima se redirigen automáticamente en lugar de cerrarse el de abajo. El auto-merge para pilas, en el que cada pull request de un grupo elegido se integra en cuanto el grupo entero está listo, se va desplegando durante las semanas siguientes. Para moverte, la pila aparece en la cabecera del pull request, Shift+J y Shift+K saltan entre sus pull requests, la timeline registra cuándo se añade o se quita uno, el webhook pull_request gana una acción stacked, y la extensión gh stack de GitHub CLI funciona con worktrees de Git.

GitHub también publicó cifras del periodo de vista previa: dice que los repositorios que usaban pilas integraron un 9 % más de código que sus pares, y que más de dos tercios del 1 % de repositorios más activos ya usan pilas y vieron una mejora del 5 % en el tiempo hasta el merge. Tómalas como mediciones de GitHub sobre su propia función, no como un estudio independiente.

Si eres el único revisor

Mucho trabajo freelance y en solitario no tiene un segundo revisor. La pila sigue compensando, por razones generales que no tienen nada que ver con las cifras de GitHub. Revisar tu propio diff de 200 líneas a la mañana siguiente encuentra cosas que revisar tu propio diff de 1.500 líneas nunca encontrará. Puedes enseñarle al cliente el paso dos funcionando antes de que exista el paso tres. Cuando algo se rompe un mes después, git bisect cae en un cambio pequeño y con nombre en lugar de en un commit gigante. Y si el propio desarrollador del cliente hereda el proyecto, recibe un historial que puede leer de verdad.

Cuándo no apilar

Una pila tiene un coste, así que debería darte algo a cambio. Sáltatela cuando el cambio ya es lo bastante pequeño como para revisarlo de una vez. Sáltatela cuando las piezas no se pueden juzgar por separado: si el primer pull request solo tiene sentido después de leer el tercero, es un único cambio, y dividirlo solo reparte la confusión en tres pestañas. Cuidado cuando la base de la pila todavía se mueve mucho, porque cada cambio ahí se propaga hacia arriba, y aunque se conserven las aprobaciones, los revisores de encima leen contra una base que se mueve. Y una pila espera a su pull request más bajo, así que en un equipo donde las revisiones tardan días, una pila de cinco niveles puede quedarse parada más tiempo que un pull request mediano y honesto.

La próxima vez que una rama pase de unos cientos de líneas, para antes de abrir el pull request y apunta los pasos que realmente siguió. Cada paso que un revisor podría aprobar por sí solo es un pull request de la pila; el resto va junto. Fuente: changelog de GitHub, «Stacked pull requests generally available» (6 de octubre de 2026).