Domina los PRs Apilados en GitHub

Los GitHub Stacked PRs son pull requests encadenadas donde cada PR depende de la anterior, permitiendo que los equipos revisen y mergeen código en cambios pequeños y focalizados sin bloquear el desarrollo paralelo. GitHub anunció gh-stack en 2026, su herramienta oficial CLI para gestionar estos flujos automáticamente, eliminando conflictos de rebase manual y acelerando significativamente el code review en refactors grandes, migraciones y features complejas de múltiples capas.

¿Qué son los GitHub Stacked PRs?

Un GitHub Stacked PR (o simplemente “stacked PR”) es una técnica de ramificación donde creás una cadena de pull requests donde cada una depende de la anterior. En lugar de tener una rama `feature/nueva-cosa` que apunta a `main`, tenés algo como: `feature/paso-1` → `feature/paso-2` → `feature/paso-3`, donde la base de `paso-2` es `paso-1`, la base de `paso-3` es `paso-2`, y así.

Podría parecer contraproducente. Pero la idea es simple: cada commit en cada rama es pequeño, cada PR es revisable en 10 minutos, y cuando mergeás la primera rama a `main`, las siguientes se rebashean automáticamente para seguir apuntando al commit correcto. El resultado: revisores felices, menos conflictos, features grandes que llegan a producción en pasos verificados.

Stacked PRs es un patrón que los equipos de infraestructura grandes (Meta, Google, Amazon internamente) usaban hace años, pero no había tooling accesible. Eso cambió con herramientas como Graphite (2022) y ahora con gh-stack, que GitHub lanzó en 2026 como solución nativa.

Cómo funcionan los Stacked PRs

Ponele que necesitás hacer un refactor grande: cambiar una arquitectura de caché en 5 archivos diferentes. Eso son cientos de líneas, múltiples cambios conceptuales, mucha superficies para bugs. En un flujo tradicional, mandás todo en un PR gigante, el revisor tarda 2 horas, vos revisás sus comentarios, hay conflictos con otras PRs que se mergearon mientras tanto, y eventualmente todo se vuelve un desastre.

Con stacked PRs, quebrás el trabajo así:

• Paso 1: agregar las nuevas funciones de caché sin tocar el código existente (100 líneas, PR pequeña)
• Paso 2: cambiar el módulo A para usar las nuevas funciones (80 líneas, depende de Paso 1)
• Paso 3: cambiar el módulo B (90 líneas, depende de Paso 2)
• Paso 4: remover el código viejo que ya no se usa (60 líneas, depende de Paso 3)

Cada PR es pequeña. El revisor entra, ve que el Paso 1 agrega funciones y nada más, aprueba en 15 minutos. Vos mergeás. Luego entra al Paso 2, ve que solo cambió el módulo A para usar las nuevas funciones, aprueba. Y así. Al final, la feature compleja llega a producción en 4 PRs verificadas de forma independiente.

Ahora, la magia: cuando mandás cambios, la herramienta (gh-stack, Graphite, lo que sea) automáticamente rebashea cada rama sobre la anterior. Si la base cambió porque mergeaste, todas las siguientes se actualizan solas. Si hay conflictos, te lo dice. Vos no estás manualmente haciendo `git rebase` y “resolviendo conflictos cada vez.

GitHub agregó soporte en la UI con un componente llamado Stack Navigator que muestra visualmente la cadena de PRs, qué está aprobada, qué está pendiente, y cuál es el orden de merge. Así los reviewers entienden el contexto sin tener que saltar entre 5 tabs.

Beneficios para equipos de desarrollo

El impacto real está en tres áreas.

Velocidad de review: una PR de 100 líneas se revisa en 15 minutos. Una PR de 1000 líneas toma 90. Si dividís en 10 PRs de 100, los reviewers pueden tomar descansos, evitan la fatiga mental, y en realidad encuentran más bugs porque están frescos. Además, si aprobar una PRs tarda 1 hora y vos dependés de ella para seguir, con stacked PRs aprovechás ese tiempo trabajando en el siguiente paso.

Menos conflictos de merge: cuando trabajás en una rama por días (o semanas en refactors grandes), inevitablemente `main` cambió. Cuando intentás mergear, hay conflictos. Con stacked PRs, mergeás el Paso 1 cada vez que está listo. El Paso 2 ya apunta a ese commit, así que el rebase es trivial. Menos fricción, menos time-to-merge.

Desarrollo paralelo sin bloqueos: si vos estás en el Paso 3 esperando aprobación del Paso 1, otro dev puede estar en otra rama trabajando en features diferentes sin pisarse. Con stacked PRs, además, otros devs pueden revisar el Paso 2 mientras vos estás escribiendo el Paso 3. Menos cuellos de botella. Lo explicamos a fondo en ejecutar agentes sin API localmente.

Hay un dato que no es menor: equipos que implementaron stacked PRs reportan una reducción de 30-40% en el tiempo total de ciclo feature-to-production. No es magia, es estructura.

Herramientas disponibles para Stacked PRs

gh-stack (oficial de GitHub, v2.0+ del CLI de GitHub) es la apuesta que hizo GitHub en 2026. Está integrado en el CLI que ya usan si trabajás con GitHub Actions. No hay cuenta externa, no hay SaaS, todo es local + GitHub. Si tu equipo ya está 100% en GitHub, probablemente sea el camino más simple.

Graphite es la opción “premium” con UI web bonita. Tenés una página que muestra tus stacks visuales, puedo ver el estado de cada PR, hay Slack integration, y funciona con GitHub, GitLab y Bitbucket. El trade-off: estás usando un servicio externo, hay modelo freemium (básico gratis, features avanzadas de pago).

stack-pr (de Modular) y spr (open-source puro) son alternativas más ligeras. Son puramente CLI, sin UI web. Si te movés bien en terminal y tus equipos también, funcionan bárbaro. El downside: cero UI, así que si alguien del equipo no es terminal-native, puede ser friccionante.

Flujo de trabajo práctico con gh-stack

Te dejo el walkthrough de cómo lo hacés en la práctica con gh-stack. Asumo que ya tenés el CLI de GitHub instalado y actualizados a v2.0+.

1. Inicializar el stack

En tu rama principal (típicamente `main` o `develop`):

gh stack init my-feature

Eso crea un “stack context” local. A partir de ahora, cualquier rama que hagas dentro de este checkout es parte del stack.

2. Crear el primer step

Hacés tu primer commit, el cambio más pequeño posible:

git add . && git commit -m "step 1: add new cache functions"

Luego:

gh stack add step-1

Eso crea una rama `step-1`, pushea, y crea una PR hacia `main`. Eso es el Paso 1.

3. Crear el segundo step

En la rama actual (que ya apunta a `step-1`), hacés el siguiente cambio pequeño:

git add . && git commit -m "step 2: update module A to use new cache"

Luego:

gh stack add step-2

Eso crea una rama `step-2` con base en `step-1`, no en `main`. Y crea una PR que dice “base: step-1”. Ahora tenés una cadena. Para más detalles técnicos, mirá consideraciones de seguridad en GitHub.

4. Pushear todo

Cuando querés actualizar GitHub con todos tus cambios (porque escribiste más commits locales):

gh stack push

Eso rebasea automáticamente cada rama sobre su base, resuelve conflictos si puede, y pushea todo. Si hay conflictos complejos, te lo dice y te da instrucciones.

5. Submitear para review

gh stack submit

Eso abre todas las PRs en paralelo (o solo las nuevas si ya hay algunas abiertas). Ahora los reviewers entran, revisan el Paso 1, aprueban. Vos mergeás. El CLI automáticamente rebashea el Paso 2 sobre el nuevo commit de `main` (después del merge del Paso 1).

Listo. Eso es el flujo. La magia está en que `push` y `submit` hacen el rebaseo automático. Vos no tocas `git rebase` nunca.

Mejores prácticas para Stacked PRs

Ojo, que hay un lado donde stacked PRs se puede volver un quilombo si no sabés qué estás haciendo.

Tamaño de cada PR: ideal entre 150 y 400 líneas. Debajo de 100 empieza a ser demasiado granular. Arriba de 500, perdés los beneficios. Un revisor debe poder leer y entender la PR en 15-20 minutos sin quebrarse la cabeza.

Descripciones claras: cada PR necesita explicar qué hace este step en particular, no la feature completa. “Refactor: extract cache module into separate file” es bueno. “Implement new caching layer for the whole app” es vago. Acordate que el revisor va a ver solo este step, sin el contexto de los pasos 4 y 5.

Revisar bottom-up: los PRs deben aprobarse en orden. El Paso 1 primero, luego el Paso 2, luego el Paso 3. Si la herramienta permite mergear en otro orden, no lo hagas. Un merge out-of-order puede quebrar la cadena. Eso sí, pedir review en paralelo está bien — mandale todas a review, pero no mergees hasta que el orden sea correcto.

Cambios unidireccionales: cada PR debería “empujar” la feature hacia adelante. No vuelvas atrás. Si en el Paso 2 te dás cuenta que el Paso 1 fue incompleto, rebashea, cambia el Paso 1, y re-submitea todo. Hacer cambios que deshacen cosas anteriores es cuando stacked PRs se vuelven un lío. Te puede servir nuestra cobertura de herramientas de IA para desarrollo.

No mezcles temas: si el Paso 2 es “cambiar módulo A” y de repente metés un fix de un bug no relacionado, dividís contexto. Mantené cada PR enfocada en su responsabilidad.

Documentación de la cadena: si la stack es larga (6+ PRs), metele un comentario en la primera PR que explique el plan general. “Este stack implementa el cambio de arquitectura en estos pasos: 1) extract, 2) refactor A, 3) refactor B, 4) delete old code.” Así los reviewers entienden dónde van.

Casos de uso ideales para Stacked PRs

Refactors grandes estructurados: mover una funcionalidad de un archivo a otro, cambiar arquitecturas de módulos, reorganizar packages. Eso se presta perfecto a stackear porque cada paso es una transformación lógica clara.

Features de múltiples capas: necesitás cambios en base de datos, luego backend API, luego frontend. Stack esos pasos. Así los reviewers especializados en cada capa revisan solo lo suyo.

Migraciones de datos: migración de un ORM a otro, cambio de schema de base de datos. Estos son perfectos para stacks: paso 1 agrega nuevos campos, paso 2 migra datos, paso 3 remueve los viejos. Cada paso es reversible si algo falla.

Cambios de infraestructura complejos: deprecating una library, cambiar cómo se logguea, actualizar versiones de dependencias en múltiples lugares. Stack permite que el revisor vea cada paso de la transición.

NO recomendado: hotfixes críticos, cambios aislados, pequeñas correcciones. Si tu PR es de 30 líneas y hay un único cambio conceptual, stackearla es overengineering. Stacked PRs tiene overhead (tenés que pensar en orden, coordinar reviews). Solo vale la pena si el trabajo tiene múltiples pasos lógicos.

Errores comunes con Stacked PRs

1. Mergear una rama intermedia antes que la anterior

Mergear el Paso 3 sin haber mergeado el Paso 1 y 2. Git técnicamente te lo permite, pero tu stack se rompe. La rama del Paso 4 sigue apuntando a Paso 3, pero Paso 3 ya está en `main`, así que cuando rebasheas, todo se vuelve un lío. Regla simple: mergeá en orden, siempre.

2. Hacer cambios en múltiples pasos simultáneamente

Estás escribiendo código, haces cambios en el Paso 1 y al mismo tiempo en el Paso 3. Cuando pusheas, Git intenta rebasear y explota todo. Solución: escribí un paso, commitea, moveté al siguiente. Secuencial. Si necesitás cambiar algo anterior, volvé a ese branch, cambié, rebase, y continuá. Ya lo cubrimos antes en alternativas y competidores de GitHub.

3. Descriptions vagas o copiadas entre PRs

Si todas tus PRs dicen “Implement new feature” sin detallar qué hace cada paso, los reviewers van a perder contexto. Cada descripción debe ser específica. “Refactor: move caching logic to separate module” vs “Refactor: update module A to use new cache interface” — son claros sobre qué cambia en cada paso.

4. Stack muy larga sin checkpoints de merge

Tenés una stack de 10 pasos, esperando que todas estén aprobadas. Una en el paso 7 tiene un problema, vuelve a review. Ahora toda la cadena está bloqueada. Mejor: mergea pasos en grupos (1-3 pasos, mergeá, confirmá que todo anda en CI, continuá). Así si algo explota, es un scope pequeño.

5. No sincronizar con `main` frecuentemente

Si `main` cambió mucho y vos seguís trabajando en el Paso 5 sin rebashear contra `main`, cuando mergees el Paso 1, toda tu stack va a tener conflictos horrendos. Mejor: cada vez que mergeás un paso, pushea de nuevo (`gh stack push`) para que todo se alinee. Más fricción en el momento, menos sorpresas después.

Preguntas Frecuentes

¿Qué diferencia hay entre Stacked PRs y un squash commit normal?

Con squash normal, vos trabajás en una rama, hacés 50 commits, luego los “aplastar” en un único commit cuando mergeás a `main`. Resultado: una sola PR gigante si querías revisar antes, o código que llega a `main` sin haber sido visto línea por línea. Con stacked PRs, cada paso es una PR que se mergea a `main`. Así el historial de `main` es limpio (un commit por step) y todo fue visto.

¿Puedo usar Stacked PRs con GitHub Actions / CI?

Sí, absolutamente. Cada PR en el stack dispara CI (tests, linters, builds) independientemente. Si el Paso 1 falla en CI, lo arreglás y re-pusheas. El Paso 2 sigue esperando aprobación. Es incluso mejor: tenés validación granular de cada paso.

¿Qué pasa si mergeo una PR fuera de orden?

La herramienta (gh-stack, Graphite, etc.) va a gritar. Te va a decir que las PRs que dependen de esa necesitan ser rebaseadas. Si ignorás la advertencia y mergeás fuera de orden, las ramas siguientes van a tener conflictos. Mejor: respetá el orden. La herramienta existe justamente para evitar eso.

¿Es compatible con otros flujos como trunk-based development?

Sí, es más: stacked PRs fit perfecto en trunk-based development. La idea de trunk-based es hacer PRs pequeñas y mergearlss rápido a `main`. Stacked PRs es exactamente eso, pero estructurado para features grandes. En realidad, stacked PRs implementan trunk-based de forma disciplinada.

¿Cuál es la herramienta más fácil para comenzar, gh-stack o Graphite?

gh-stack si ya usás CLI de GitHub y querés algo sin dependencias externas. Graphite si tu equipo prefiere UI visual y estás dispuesto a integrar un servicio SaaS. gh-stack tiene curva más plana, Graphite es más intuitivo visualmente.

Conclusión

Stacked PRs es una técnica que pasó años siendo secreto de equipos gigantes de infraestructura, pero en 2026 finalmente llegó a la mayoría con herramientas accesibles. GitHub lo entendió y lanzó gh-stack como solución nativa.

El punto no es usar stacked PRs para todo. Es para refactors grandes, features complejas multi-capa, y cambios de arquitectura donde partir el trabajo en pasos lógicos tiene sentido. Si tu PR es de 100 líneas, stackearla es overkill.

Pero si necesitás hacer un refactor de 1000 líneas, stacked PRs cambia el juego: reviews más rápidas, código que llega a producción verificado paso a paso, menos conflictos de merge, y un registro limpio en Git. La inversión en aprenderlo vale cuando lo necesitás.

Empezá con una stack pequeña (3-4 pasos), sentí cómo funciona, y después escalá a features más complejas. Y ojo: esto funciona mejor en equipos que ya tienen disciplina de code review. Si tu equipo tiende a mergear sin revisar, stacked PRs va a ser un obstáculo, no una herramienta.

Fuentes

• GitHub gh-stack — CLI oficial para Stacked PRs
• Graphite — Herramienta visual para gestionar Stacked PRs
• stack-pr de Modular — Alternativa open-source para Stacked PRs
• LogRocket — Guía sobre Stacked PRs en GitHub
• Git Tower — Introducción a Stacked PRs y mejores prácticas