El martes 6 de octubre de 2026, GitHub anunció en su registro de cambios oficial que las pull requests apiladas, conocidas en inglés como stacked pull requests, ya están disponibles de forma general. La función permite dividir un cambio grande en una cadena de pull requests más pequeñas y centradas, que pueden revisarse de forma independiente y fusionarse juntas. Está disponible en todos los planes de github.com y llegará a GitHub Enterprise Server en una próxima versión.
Una pila está formada por dos o más pull requests en el mismo repositorio. La primera, la inferior, apunta a la rama troncal, normalmente la rama principal del proyecto. Cada pull request siguiente apunta a la rama de la que tiene debajo. Según la documentación de GitHub, los cambios fundamentales, como tipos compartidos o esquemas de base de datos, van en las capas bajas, y el código que depende de ellos, como rutas de API o componentes de interfaz, en las superiores.
La ventaja principal es no tener que esperar. Con una pila, un desarrollador puede abrir una nueva pull request encima de otra que sigue abierta, en lugar de esperar a que se fusione. Cada capa muestra solo su propio diff, de modo que los revisores ven cambios pequeños en vez de una gran pull request. GitHub argumenta que las revisiones pequeñas son más rápidas, se leen con más atención y tienen menos probabilidades de quedarse obsoletas y acumular conflictos.
La empresa vincula explícitamente la función con la IA. La documentación explica que, cuando se genera mucho código a la vez, a menudo con agentes de IA, una pila da a cada cambio un lugar propio: un agente completa una tarea y empieza la siguiente que se apoya en ella, lo que encaja con el patrón de «una pull request por tarea, cada una basada en la de abajo». Así, las dependencias quedan registradas de forma explícita en lugar de mezclar cambios en una sola rama.
GitHub aportó cifras de la etapa de vista previa pública. Según la compañía, los repositorios que usan pilas fusionaron un 9% más de código que repositorios comparables, y más de dos tercios del 1% de repositorios más activos ya utilizan pull requests apiladas, con una mejora del 5% en el tiempo hasta la fusión. Son datos del propio fabricante, sin auditoría externa, pero indican una adopción notable entre los proyectos más intensos.
La versión general añade cambios en la forma de fusionar y rebasar. Cuando una pila sin cambios se actualiza porque la rama base avanzó, la opción Rebase stack conserva ahora las aprobaciones, incluso en repositorios que descartan aprobaciones obsoletas. Durante ese proceso, GitHub crea commits de reemplazo firmados que preservan la autoría original, y los usuarios con permisos para saltarse reglas del repositorio pueden usarlos para fusionar la pull request inferior pendiente.
También mejora la integración con la cola de fusión: una pila entra y sale de la merge queue como un único grupo, y con el método de commit de fusión GitHub crea un commit por cada pull request en lugar de uno para todo el grupo. Si se elimina la rama base de una pila, GitHub la redirige automáticamente en lugar de cerrar su pull request inferior. La fusión automática de pilas se desplegará durante las próximas semanas.
La navegación también cambia. La información de la pila se muestra siempre en la cabecera fija de la página de cada pull request, y los atajos de teclado Mayúsculas+J y Mayúsculas+K permiten saltar entre capas. La línea temporal registra cuándo una pull request entra o sale de una pila, y el webhook pull_request incluye ahora una acción «stacked». La extensión gh stack de GitHub CLI admite worktrees de Git y es más rápida al inicializar, cambiar de rama y navegar.
Para los agentes existe una vía específica. Además de la extensión, que se instala con gh extension install github/gh-stack, GitHub ofrece una skill para agentes, gh-stack, que se instala con gh skill install github/gh-stack. La CLI incluye comandos para iniciar una pila, añadir capas, subirlas, enviarlas, verlas, sincronizarlas, rebasarlas y fusionarlas, y las API REST y GraphQL exponen la pertenencia de cada pull request a una pila.
Las reglas de calidad se aplican a toda la cadena. Los requisitos de fusión se determinan por la rama base de la pull request inferior, y las reglas de protección de ramas, como las aprobaciones de propietarios de código, se aplican a cada pull request de la pila, incluso a las intermedias que no apuntan directamente a la rama principal. Las comprobaciones de integración continua de la rama principal también se ejecutan en todas las capas, no solo en la inferior.
Hay límites. Las pilas deben fusionarse de abajo arriba: fusionar la pull request superior fusiona todas las que tiene debajo, y fusionar una intermedia arrastra las inferiores mientras las superiores se redirigen a la base. Todas las ramas deben estar en el mismo repositorio, por lo que no se admiten pilas entre forks, y la función no está disponible en GitHub Desktop. Quien fusione mediante la API debe usar la API de fusión asíncrona para pilas.
Los primeros usuarios se muestran entusiastas. «Me bastó una fusión con las Stacked PRs de GitHub para concluir que es increíble», dijo Charlie Marsh, fundador de Astral, citado por GitHub. David Mostoller, ingeniero de software de Comcast, destacó que ver cada rama de la pila en la interfaz, comprobar su estado y navegar entre ellas facilita mucho gestionar y revisar muchas pull requests dependientes dentro de un equipo.
El contexto ayuda a entender por qué GitHub insiste en el ángulo de la IA. A medida que los agentes de programación producen más código, el cuello de botella se desplaza hacia la revisión humana. Una gran pull request generada por un agente es difícil de evaluar; una serie de cambios pequeños y ordenados, cada uno con su propia validación, encaja mejor con la supervisión que exigen los equipos. Las pilas no resuelven la calidad del código, pero sí ordenan su revisión.
En conclusión, la disponibilidad general de las pull requests apiladas convierte en función nativa una práctica que muchos equipos ya aplicaban con herramientas externas. Las mejoras en aprobaciones, firmas, cola de fusión y automatización reducen la fricción, y el soporte para agentes muestra hacia dónde se mueve el desarrollo de software. La clave será que los equipos usen las pilas para revisar mejor, no solo para fusionar más rápido.
