Stacked PRs en GitHub: cómo dividir un cambio grande en PRs pequeños

Si alguna vez abriste un PR de 800 líneas con quince archivos modificados y te quejaste del reviewer por no querer mergearlo, bienvenido al club. Los stacked pull requests son exactamente la respuesta a esa situación: partir ese cambio enorme en una serie de PRs pequeños y ordenados, cada uno con un foco claro. GitHub las puso en preview público el 30 de julio de 2026, y la verdad es que vale la pena probar el flujo.

Qué cambia con los stacked PRs

Hasta ahora, si querías meter un cambio grande en main, tenías dos opciones feas:

Un PR gigante que nadie quiere revisar y termina esperando dos semanas.
Varios PRs independientes pero que se pisan entre sí, hay que ir rebaseando uno cuando cambia el otro, y al final del día nadie sabe cuál depende de cuál.

Las stacked PRs atacan el segundo problema. Cada PR de la pila sabe que vive encima de otro. GitHub te muestra un mapa del stack arriba de cada PR, y cuando mergeas el de abajo, los de arriba se rebasean y cambian de base automáticamente. Nada de tocar git rebase a mano ni de andar rezando para que el CI siga verde.

Definición rápida: un stack es una serie ordenada de PRs donde cada uno representa una capa focalizada del cambio total. La capa base va primero; arriba se apilan las que vienen después.

El changelog oficial lo explica así: un stack es una serie ordenada de PRs pequeños donde cada uno representa una capa de un cambio más grande, y cada capa se revisa por separado. En resumen: en vez de un PR de 800 líneas, tienes cinco de 150 líneas que se mergean una tras otra.

Cómo se ven en la práctica

El modelo mental cambia respecto al PR clásico. Ya no piensas en un PR aislado sino en una pila con tres elementos:

El PR base. Es el primero de la pila. No depende de nadie y apunta a main. Aquí va el cimiento: una migración de base de datos, un refactor de tipos, lo que sea el "andamiaje".
Los PRs de en medio. Cada uno declara explícitamente "dependo de #X". Apuntan a la rama del PR inferior, no a main. Aquí viven las features que se construyen sobre la base.
El PR tope. Es el último y el que entrega valor al usuario. Si lo mergeas cuando está listo, entra junto con todas las capas de debajo que falten, en una sola operación.

GitHub te muestra la dependencia visualmente en la página del PR: un mapa del stack indica en qué capa estás, y el diff de cada PR muestra solo los cambios de esa capa.

Tip: nómbralas con prefijos para no perderte. Algo como feat/stack-01-types, feat/stack-02-endpoint, feat/stack-03-ui. Tres minutos que te ahorran tres horas.

Cuándo tiene sentido usarlas

No todo PR necesita ser un stack. Si tu cambio cabe en 200 líneas, haz un PR normal y listo. El valor aparece cuando se cumple alguna de estas:

El cambio toca más de 3 áreas distintas del código. Por ejemplo, un refactor que renombra un tipo, modifica el storage, y actualiza la UI. Cada área por separado es un PR razonable.
Quieres revisar y mergear por capas. A veces la migración de la base de datos puede entrar hoy aunque la UI todavía esté verde. Con el stack, mergeas esa primero y sigues con el resto mañana.
Quieres feedback temprano. Abres el primer PR y en dos horas ya tienes comentarios sobre el approach. Si tenías todo en un solo PR, esos comentarios llegaron cuando ya tenías 600 líneas más encima.

Lo que no tiene sentido: cambios que sí o sí tienen que entrar atómicos (una migración de schema reversible depende de la siguiente), o features pequeñas donde partirlo genera más fricción que valor.

Cómo armar un stack sin que se rompa

El workflow manual con git puro es famoso por ser frágil: branches que se desactualizan, force-push que rompe al reviewer, y el clásico "rebasing, un momento". GitHub ofrece una extensión de la CLI específica para esto (gh-stack), además de la web, la app móvil y los coding agents como Copilot. El flujo es:

Crear la rama base y abrir el primer PR contra main. Nada raro aquí, es tu flujo de siempre.
Encima de esa rama, añadir la siguiente rama y su PR. Cada PR apunta a la capa de debajo; la extensión gh-stack o la UI web le dicen a GitHub "este PR vive encima del anterior".
Cuando mergeas el base, los PRs de arriba se rebasean y apuntan a la nueva base automáticamente. El reviewer ve el diff actualizado sin hacer nada.

El punto crítico es no pushear las ramas del stack a main directamente mientras el stack está vivo. Cada rama apunta "arriba" en la pila; el merge real sucede cuando el base entra, y ahí GitHub se encarga del resto.

# Instalar la extensión oficial de la CLI
gh extension install github/gh-stack

Atención: los subcomandos de gh-stack pueden cambiar mientras la feature madura; consulta la ayuda de la extensión (gh stack --help) o la documentación en gh.io/stacks. Si algo no te sale desde la CLI, monta el stack desde la pantalla del PR y listo.

Cómo cambian tus PRs cuando los adoptas

El primer cambio cultural es aceptar que un PR no vive solo. Tu feat/stack-02 deja de apuntar a main y pasa a apuntar a feat/stack-01. Esto rompe una de las reglas que muchos tenemos internalizadas ("siempre contra main"), pero es exactamente el punto: el stack existe porque no todas las capas están listas para main todavía.

El segundo cambio es que el diff de cada PR se vuelve más honesto. Cuando revisas feat/stack-03-ui, ya sabes que feat/stack-01-types está mergeado y el contexto es estable. Puedes comentar la UI sin miedo a que mañana el archivo cambie porque el reviewer pidió renombrar un tipo. Esto es enorme para el tiempo de revisión.

El tercero, y a veces subestimado: los stacks bajan la barra para decir "lo abro igual". Antes, si tu cambio era grande, lo guardabas para "el momento indicado". Con stacks, abres el PR del andamiaje y ya está circulando.

Trade-offs reales

No todo es de color de rosa. Algunas cosas que vas a tener que aceptar:

Más PRs significa más merges. Tu CI va a correr más veces. En proyectos con tests lentos esto duele.
El stack puede quedar a medias. Si mergeas el primero pero el tercero se rompe y nadie lo arregla, tienes una feature colgada en el limbo. Hay que ser disciplinado.
Los reviewers tienen que entender el modelo. El primer PR que abras como stack va a recibir algún "por qué este PR no va contra main?". Es normal; una vez que lo explicas, el resto fluye.

Si te toca un equipo que todavía está migrando a trunk-based o que apenas sabe qué es un PR, empezar con stacks puede ser demasiada fricción. Prueba primero con un equipo pequeño en un cambio de tamaño medio y evalúa.

Cómo probarlo hoy

El preview público está abierto desde el 30 de julio y GitHub lo fue activando en todos los repositorios durante los días siguientes, así que no hace falta activar nada. El soporte en merge queue llega de forma progresiva.

Actualización (octubre de 2026): GitHub anunció la disponibilidad general de las stacked PRs el 6 de octubre.

Para probarlo sin riesgo, monta un repo de prueba y un cambio en tres capas:

gh repo create sandbox-stacks --public --clone
cd sandbox-stacks
gh extension install github/gh-stack
echo "# demo" > README.md
git checkout -b feat/stack-01-readme
git add README.md
git commit -m "stack 01: bootstrap readme"
git push -u origin feat/stack-01-readme

Abre el PR de esa rama contra main y, a partir de ahí, ve apilando ramas y PRs encima con gh-stack o desde la web.