El 6 de octubre de 2026, GitHub anunció la disponibilidad general de las pull requests apiladas (stacked pull requests), una función que permite dividir un cambio grande en varias PR más pequeñas, revisables de forma independiente y fusionadas juntas. La función estaba en vista previa pública desde el 30 de julio de 2026; ya está disponible en todos los planes de github.com, con una versión para GitHub Enterprise Server anunciada sin fecha concreta.
Lo que mostró la vista previa
Durante la vista previa, GitHub indica que los repositorios que usan stacks fusionaron un 9% más de código que repositorios comparables, con una mejora del 5% en el tiempo de fusión. Más de dos tercios de los repositorios del 1% más activo de GitHub ya usan este mecanismo, una señal de adopción entre equipos con alto volumen de contribuciones.
Fusión y rebase: el cambio de fondo
El paso a disponibilidad general afecta sobre todo a la mecánica de fusión. El comando rebase stack ahora conserva las aprobaciones ya dadas sobre código sin cambios, incluso en repositorios configurados para invalidar aprobaciones con cada nuevo commit. Los commits rebasados siguen firmados si las reglas de rama lo exigen o si los commits originales lo estaban, y se conserva la autoría original.
Un stack entra y avanza en la cola de fusión como un único grupo de fusión: con el método de merge commit, GitHub crea un commit de fusión por PR. Si se elimina la rama base de un stack, el stack se redirige automáticamente en lugar de cerrar su PR inferior, lo que permite stacks que parten de otros stacks.
| Aspecto | Antes (vista previa) | En disponibilidad general |
|---|---|---|
| Rebase | Invalidaba las aprobaciones | Conserva las aprobaciones sobre código sin cambios |
| Fusión | PR por PR | Grupo de fusión único vía la cola de fusión |
| Rama base eliminada | Cierre de la PR inferior | Redirección automática del stack |
| Fusión automática | No disponible | Despliegue progresivo durante varias semanas |
Navegación y automatización
La información del stack aparece ahora en la cabecera persistente de la página de PR y en la lista de pull requests. Los atajos Shift+J y Shift+K permiten moverse entre las PR de un mismo stack, y la línea de tiempo muestra cuándo una PR se une o sale de un stack. El webhook pull_request expone ahora una acción stacked cuando una PR se une a un stack, por ejemplo para ajustar la estrategia de caché de los workflows de GitHub Actions según si una PR pertenece a un stack o no.
La extensión de CLI gh stack gana soporte para worktrees de Git, además de una inicialización, checkout y navegación más rápidos. Un desarrollador que gestiona varios stacks a la vez ya no necesita múltiples clones para hacerlo.
gh stack create feature/refonte-auth
gh stack push
gh stack sync # rebase + mise à jour de la stack entière
gh stack ls # liste les PR de la stack courante
Más de dos tercios de los repositorios del 1% más activo de GitHub ya usan las pull requests apiladas.
La fusión automática de los stacks se despliega progresivamente durante varias semanas: un equipo que todavía no la ve en la configuración de su repositorio no tiene nada que configurar por su parte, es un despliegue del lado de GitHub.
Para los equipos que ya apilan PR a mano
Los equipos que ya apilaban sus PR manualmente, mediante convenciones de nombres o herramientas de terceros, pueden migrar sin cambiar su forma de trabajar: los mismos hábitos de CLI siguen siendo válidos, GitHub añade la mecánica de fusión por encima. El beneficio principal sigue siendo la calidad de revisión: una PR de 2000 líneas se convierte en cinco PR de 400 líneas, cada una con su propio contexto de revisión.
Lo que hay que recordar
Las pull requests apiladas salen de la vista previa con una mecánica de fusión más robusta: aprobaciones conservadas durante el rebase, fusiones agrupadas vía la cola de fusión, y una extensión de CLI más rápida. La función está disponible en todos los planes de github.com desde hoy, sin ninguna acción requerida para los repositorios que todavía no la usan.
Los stacks resuelven un problema real de revisión de código, pero exigen una disciplina que muchos equipos todavía no tienen: si una PR en medio de un stack cambia radicalmente tras una revisión, todo lo que viene después debe rebasearse, y ahí es donde el rebase automático de GitHub demuestra realmente su valor. Vale la pena probarlo antes de convertirlo en convención de equipo. — Simon Janvier
Para profundizar: el anuncio oficial en el changelog de GitHub.
