Las stacked pull requests de GitHub ya están disponibles para todos

GitHub puso las stacked pull requests a disposición de todos el 6 de octubre de 2026, en todos los planes de github.com. Una pila permite a un desarrollador dividir un cambio grande en una cadena de pull requests pequeñas que se revisan de una en una y luego se fusionan juntas. La función estaba en vista previa pública desde el 30 de julio, y GitHub dice que los equipos que la usan ya fusionan más código.

Qué es una stacked pull request

Una pull request (PR) pide fusionar una rama de código en otra. Las PR grandes son lentas de revisar, porque el revisor tiene que entenderlo todo a la vez.

Una pila divide ese trabajo en capas. Cada PR apunta a la rama que tiene debajo, así que cada una muestra solo su propia parte de los cambios. La PR inferior apunta a la rama principal, a menudo llamada trunk. Según el changelog de GitHub, cada capa recibe sus propias revisiones y comprobaciones antes de que las capas se integren juntas.

La fusión va de abajo arriba. CCLeaks, que publicó una guía de configuración el 8 de octubre, explica que fusionar una PR también integra todas las PR sin fusionar que tiene debajo. Fusionar la PR superior fusiona toda la pila. Las reglas de rama siguen aplicándose a cada capa, incluidas las revisiones obligatorias, las comprobaciones de estado y los code owners.

Qué cambió con la disponibilidad general

El changelog del 6 de octubre enumera estos cambios desde la vista previa:

Cambio	Qué hace
Las aprobaciones sobreviven a los rebases	Hacer rebase de una pila conserva las aprobaciones sobre el código sin cambios, incluso en repositorios que descartan aprobaciones obsoletas
Commits firmados	Los commits reescritos durante un rebase de la pila siguen firmados y conservan a su autor original
Merge queue	Una pila entra en la cola de fusión como un solo grupo y se integra de una vez
Commits de fusión	Con el método de merge commit, cada PR de la pila recibe su propio commit de fusión
Rama base eliminada	La pila se redirige en lugar de cerrarse su PR inferior
Fusiones con omisión de reglas	Los usuarios que pueden omitir las reglas del repositorio pueden fusionar la PR sin fusionar más baja

La fusión automática para pilas todavía se está desplegando «en las próximas semanas», según GitHub. El encabezado de la PR muestra ahora los detalles de la pila, y la línea de tiempo registra cuándo una PR entra en una pila o sale de ella. Los webhooks ganan una acción stacked en el evento pull_request. GitHub Enterprise Server, la edición autoalojada, recibirá las pilas «en una próxima versión».

Las cifras que da GitHub

GitHub dice que los repositorios que usan pilas fusionaron un 9 % más de código que sus pares. También informa de una mejora del 5 % en el tiempo hasta la fusión. Son cifras de la propia GitHub, y el changelog no explica cómo eligió el grupo de comparación.

Los primeros usuarios parecen satisfechos. «Me bastó una fusión con las Stacked PRs de GitHub para concluir que es increíble», dice Charlie Marsh, fundador de Astral, citado en el changelog. En la publicación de la vista previa de julio, Tim Neutkens, responsable de Next.js en Vercel, dijo: «Llevamos los últimos meses usando las stacked PRs de GitHub para Next.js».

Cómo empezar una pila

Las pilas se manejan con gh stack, una extensión para la GitHub CLI, la herramienta de línea de comandos de GitHub. CCLeaks indica como requisitos GitHub CLI 2.90.0 o posterior y Git 2.20 o posterior. La versión GA añade soporte para los worktrees de Git, que permiten que un repositorio mantenga varias ramas extraídas en carpetas separadas.

El flujo básico, según la guía de CCLeaks:

1. Instala la extensión con gh extension install github/gh-stack.
2. Ejecuta gh stack init para empezar una pila y luego gh stack add <branch> para cada capa.
3. Ejecuta gh stack submit para abrir las PR y gh stack view para ver la cadena.
4. Ejecuta gh stack rebase cuando la rama base avance.

La publicación de la vista previa de julio dice que las pilas también se pueden crear en github.com, en la app móvil de GitHub o mediante un agente de programación como GitHub Copilot con la skill gh-stack. En la vista web, Shift+J y Shift+K permiten moverse entre las PR de una pila.

Límites que conviene conocer antes

La función tiene límites claros. CCLeaks enumera estos:

• Un solo repositorio. Todas las ramas deben estar en el mismo repositorio, así que las pilas entre forks no funcionan.
• Solo líneas rectas. Una pila no puede ramificarse; una PR no puede tener dos hijas.
• Sin GitHub Desktop. La aplicación de escritorio no admite pilas.
• Los endpoints de fusión antiguos fallan. Los endpoints heredados de la API de fusión de PR no pueden fusionar una pila.
• Grupos de cola más grandes. El grupo de una pila en la cola de fusión puede superar el tamaño máximo configurado hasta en un 50 %. Expulsar una PR también retira todas las PR que tiene encima.

Qué significa para los desarrolladores

Los equipos que dividen a mano trabajos grandes en ramas dependientes tienen ahora un flujo integrado. Antes de cambiar, conviene revisar algunas cosas.

• Revisa tu automatización. Los bots que fusionan a través de endpoints antiguos de la API fallarán con las pilas. CCLeaks dice que los datos de la pila llegan a GitHub Actions como github.event.pull_request.stack, y que el campo stack de la API REST es null para las PR individuales. Actualiza los bots de fusión para que lo lean.
• Revisa los límites de la cola de fusión. Si tu cola limita el tamaño de los grupos para proteger la capacidad de CI, una pila puede llevar un grupo hasta un 50 % por encima de ese límite.
• Los colaboradores desde forks tendrán que esperar. Los proyectos de código abierto que aceptan cambios desde forks aún no pueden apilar esas PR.
• Planifica más adelante las actualizaciones de Enterprise Server. Los clientes autoalojados no tienen fecha, solo «una próxima versión».
• Pruébalo con un cambio grande. Una refactorización que toca muchos archivos es una primera prueba natural. Divídela en tres o cuatro capas y comprueba si las revisiones vuelven antes.

La cifra del 9 % es lo que GitHub afirma sobre su propio producto. Tus propios tiempos de revisión, antes y después, son el número que vale la pena seguir.