Stacked PRs en GitHub: cómo dividir un cambio grande en PRs chicos

Si alguna vez abriste un PR de 800 líneas con quince archivos modificados y te rezongaste al 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 chicos y ordenados, cada uno con un foco claro. GitHub las puso en preview público el 30 de julio de 2026, y la verdad 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:

1. Un PR gigante que nadie quiere revisar y termina esperando dos semanas.
2. 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 arriba de otro. GitHub te muestra explícitamente la dependencia (#42 depends on #41), y cuando mergueás el de abajo, el de arriba se actualiza 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í: las stacked PRs "rompen cambios grandes en pedazos chiquitos y revisables. Son una serie ordenada de PRs donde cada uno representa una capa focalizada de tu cambio". En criollo: en vez de un PR de 800 líneas, tenés 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 pensás 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. Acá 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. Acá viven las features que se construyen sobre la base.
• El PR tope. Es el último y el que entrega valor al usuario. Cuando mergueás todo en orden de abajo hacia arriba, este queda listo para entrar.

GitHub te renderiza la dependencia visualmente en la página del PR. Ves qué rama es el target, qué PR vive debajo en el stack, y el botón de merge te muestra claramente el orden.

Tip: nombralas 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 entra en 200 líneas, hacé 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.
• Querés 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, mergueás esa primero y seguís con el resto mañana.
• Querés feedback temprano. Abrís el primer PR y en dos horas ya tenés 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 chicas 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 provee una CLI específica para esto, así que lo más prolijo es:

1. Crear la rama base y abrir el primer PR contra main. Nada raro acá, es tu flujo de siempre.
2. Desde esa rama, crear la siguiente con un comando que la registre como dependiente. La sintaxis exacta la maneja la gh CLI nueva (gh stack-pr) o el botón de la UI cuando armes el PR; cualquiera de las dos le dice a GitHub "este PR vive arriba del anterior".
3. Cuando mergueás el base, GitHub actualiza automáticamente el target del siguiente PR para apuntar a main (en vez de a la rama ya mergeada). 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.

# Una vez instalada la CLI con soporte para stacks:
gh stack-pr create feat/stack-02-endpoint --base feat/stack-01-types
gh stack-pr create feat/stack-03-ui       --base feat/stack-02-endpoint

Atención: durante el preview algunas opciones viven sólo en la UI web. Si la CLI todavía no te muestra los subcomandos, no te asustes: armá el stack desde la pantalla del PR y andá igual.

Cómo cambian tus PRs cuando los adoptás

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 revisás feat/stack-03-ui, ya sabés que feat/stack-01-types está mergeado y el contexto es estable. Podés 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, abrís el PR del andamiaje y ya está circulando.

Trade-offs reales

No es todo color de rosas. 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 mergueás el primero pero el tercero se rompe y nadie lo arreglo, tenés un feature colgado en el limbo. Hay que ser disciplinado.
• Los reviewers tienen que entender el modelo. El primer PR que abrís como stack va a recibir algún "por qué este PR no va contra main?". Es normal; una vez que lo explicás, 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. Probá primero con un equipo chico en un cambio de tamaño medio y evaluá.

Cómo probarlo hoy

El preview público está abierto desde el 30 de julio. Para entrar:

1. Andá a la configuración de tu cuenta en GitHub y buscá la sección "Feature preview".
2. Activá "Stacked pull requests".
3. Esperá unos minutos a que se propague y ya te aparece el flujo nuevo en la pantalla de crear PR.

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

gh repo create sandbox-stacks --public --clone
cd sandbox-stacks
echo "# demo" > README.md
git checkout -b feat/stack-01-readme
git add README.md
git commit -m "stack 01: bootstrap readme"
gh stack-pr create feat/stack-02-config --base feat/stack-01-readme

Y a partir de ahí seguís apilando.

Lo que me llevo

Después de varios años peleándome con PRs grandes, las stacked PRs no me parecen una moda: son la implementación oficial de un flujo que la mayoría de los equipos senior ya venía improvisando con branches nombradas con prefijos y rebase manual. Que GitHub lo banque nativamente cambia dos cosas: le saca el miedo al que nunca lo intentó, y le da una herramienta seria al que ya lo hacía a mano.

Si querés ver cómo encaja esto con tus deploys automáticos, te recomiendo repasar mi post sobre GitHub Actions para sincronizar Obsidian con tu blog, donde explico cómo orquestar varios repos con Actions. El mismo principio aplica: cuanto más chica y enfocada es la unidad que se mueve, más simple es automatizar el resto.

Y si estás armando un blog técnico con Obsidian + Next.js como yo, también te sirve leer Cómo construí mi blog con Next.js y Obsidian: ahí se ve por qué a veces un cambio toca tres archivos y a veces diez, y por qué stacks hacen la diferencia en esos segundos casos.

Por ahora, recomiendo probar el preview en un side-project antes de meterlo en el repo del trabajo. Cuando el flujo te cierre, vas a empezar a abrir PRs sin pensarlo.