⚡ Tecnología
GitHub lanza Stacked PRs: adiós a los PRs monstruo de 5.000 líneas
¿Cuántas veces te tocó revisar un pull request con 5.000 líneas cambiadas, 40 archivos y una descripción que dice solo "refactor"?
Lo dejaste para después. Todos lo dejaron para después. Y el PR quedó ahí, pudriéndose, mientras el autor hacía rebase a mano cada dos días.
Ese infierno tiene los días contados. El 30 de julio GitHub lanzó Stacked PRs en public preview, y es el cambio más importante en el flujo de pull requests en años.
El problema que todos conocemos (y nadie resolvía)
Los PRs gigantes son un anti-patrón. Revisar 50 archivos de una sentada es imposible: el reviewer se cansa, aprueba sin leer o bloquea el merge por semanas.
Las alternativas existían, pero eran herramientas de terceros (Graphite, Stacked PRs de GitLab) o workflows manuales con ramas encadenadas que se rompían en cada rebase.
El resultado: equipos lentos, cuellos de botella y código que se pudre en ramas mientras el main se queda sin la feature.
Qué son los Stacked PRs de GitHub
La idea es simple y elegante: en vez de un PR monstruo, abres una serie ordenada de PRs pequeños, donde cada uno representa una capa del cambio.
Cada PR de la pila se revisa y se chequea de forma independiente, sin esperar a que el de abajo esté mergeado.
¿Quieres ver cómo encaja tu cambio en el todo? Hay un stack map en la parte superior del PR que muestra la relación entre capas.
Y lo mejor: cuando todo está listo, mergeas la pila completa en un solo clic — o mergeas solo las capas que te interesan y las demás se reajustan automáticamente.
No es humo: lo están usando en producción
GitHub lo probó con equipos reales antes de anunciarlo. Los testimonios son contundentes:
Tim Neutkens, líder de Next.js en Vercel: "Llevamos meses usándolo. Nos ayudó a introducir cambios más pequeños mientras lanzábamos features más grandes".
John Resig, creador de jQuery: "Landé 5 PRs apilados en la merge queue de una sola vez. A+++. Esto elimina muchísima fricción".
El CTO de TED lo dice más claro: "La IA hizo a nuestros devs mucho más productivos, pero creó un nuevo cuello de botella: PRs tan grandes que los reviewers sufrían. Stacked PRs lo resolvió".
Cómo empezar a usarlo hoy (gratis)
Está en public preview para todos los repositorios, y el rollout ya empezó. Para crearlo desde la terminal:
gh extension install github/gh-stackY listo. Creas tu primera rama con PR, luego ramas encima de ella, y cada PR apunta a la capa inferior.
Funciona desde github.com, GitHub CLI, la app móvil e incluso con agentes de codificación tipo GitHub Copilot vía el skill de gh-stack.
Las branch protections y checks obligatorios que ya usas siguen aplicando sin cambios. Cero fricción de adopción.
Mi opinión (polémica incluida)
Hay una ironía enorme en este anuncio: la IA generó el problema y GitHub viene a arreglarlo. Los coding agents escriben código a una velocidad que ningún humano puede revisar al mismo ritmo.
Por eso los PRs se volvieron monstruos. Y por eso los equipos que adopten Stacked PRs van a tener una ventaja real sobre los que sigan con el PR gigante.
Para los devs latinos en equipos remotos, esto es oro puro. Cuando el review es la moneda de cambio en un equipo distribuido, poder revisar 200 líneas en vez de 5.000 significa que tu código llega a producción hoy, no en tres semanas.
La única crítica: llega tarde. Graphite construyó un negocio entero sobre esta idea, y Cursor lo acaba de comprar. GitHub recién lo integra de forma nativa. Pero cuando el gigante se mueve, el ecosistema lo sigue.
El futuro de los PRs
Los PRs monstruo no van a desaparecer de un día para otro. Hay hábitos que cuestan cambiar.
Pero a partir de hoy, abrir un PR de 5.000 líneas ya no es una decisión técnica: es una falta de respeto al reviewer. No hay excusa.
Comparte esto con ese compañero que te mandó un PR de 40 archivos un viernes a las 6 de la tarde. 😤
¿Y tú? ¿Ya probaste Stacked PRs, o sigues defendiendo el PR gigante? 👇