GitHub Stacked PRs: revisa código 10x más rápido

El problema que nadie quiere admitir en revisión de código

El 70% del tiempo que un equipo de desarrollo pierde en revisión de código se debe a pull requests demasiado grandes. Un PR con 2.000 líneas modificadas no se revisa bien: se aprueba sin leerlo. GitHub lo sabe, y por eso lanzó GitHub Stacked PRs con la CLI gh stack, una solución nativa para dividir cambios grandes en piezas pequeñas y manejables.

Si lideras un equipo de ingeniería o eres el único desarrollador de tu startup, este cambio en el flujo de trabajo puede reducir drásticamente los cuellos de botella en tu ciclo de entrega.

¿Qué son los stacked pull requests y cómo funcionan?

Los stacked pull requests (también llamados PRs dependientes, encadenados o incrementales) son una secuencia de pull requests donde cada uno se basa en el anterior. En términos de Git, significa crear ramas que se ramifican desde otras ramas de feature, no directamente desde main.

👥 ¿Quieres ir más allá de la noticia?

En nuestra comunidad discutimos las tendencias, compartimos oportunidades y nos ayudamos entre emprendedores. Sin humo, solo acción.

👥 Unirme a la comunidad

El flujo técnico es así:

Creas feat1 desde main, haces tus cambios y abres PR #1.
Sin esperar a que se apruebe, creas feat2 desde feat1, avanzas con el siguiente bloque lógico y abres PR #2.
Cuando GitHub mergea PR #1, actualiza automáticamente la base de PR #2 para que apunte a main.

El resultado: tu equipo puede revisar piezas pequeñas y coherentes en paralelo, mientras tú sigues desarrollando sin bloqueos.

¿Qué hace exactamente la CLI gh stack?

La herramienta oficial de GitHub, accesible desde la CLI como gh stack, aporta soporte nativo para gestionar estas pilas directamente desde la terminal. Los comandos clave incluyen:

gh stack new — crea una nueva pila de PRs a partir de commits locales.
gh stack push — sube los cambios de toda la pila a GitHub.
gh stack rebase — realiza un rebase en cascada cuando cambia la base de la pila.
gh stack squash — consolida commits antes del merge final.

La interfaz de GitHub también muestra la navegación visual entre PRs de la misma pila, lo que facilita que los revisores entiendan el orden y el contexto sin necesidad de leer el historial de commits.

GitHub Stacked PRs vs. las alternativas del mercado

Antes de que GitHub ofreciera soporte nativo, el ecosistema de herramientas para stacked PRs ya era activo. Conocerlas te ayuda a tomar la mejor decisión para tu equipo:

Graphite: La alternativa más popular antes del soporte nativo. Tomas Reimers, cofundador de Graphite, popularizó el concepto de "10x engineer vía stacked PRs" en GitKon 2022. Automatiza flujos colaborativos avanzados, pero tiene curva de aprendizaje y no es la solución oficial de GitHub.
stack-pr (Modular): Herramienta open-source anunciada en julio de 2024 por Modular, la empresa detrás del lenguaje Mojo. Simple, orientada a CLI, pero en estado temprano de desarrollo.
Aviator: Enfocada en equipos enterprise con pipelines complejos. Más plataforma que herramienta.
Stacked Git / git-branchless: Soluciones basadas en Git puro, sin integración directa con la UI de GitHub. Útiles para flujos locales, menos para equipos remotos.

La ventaja de gh stack frente a todas ellas es clara: es la solución oficial, integrada de forma nativa con GitHub CLI y con soporte directo en la interfaz web de GitHub.

Beneficios reales para equipos que lo han implementado

Los beneficios de los stacked PRs van más allá de la velocidad de revisión. Dave Pacheco, ingeniero senior con amplia experiencia en workflows de GitHub, documentó en 2025 que el modelo de stacked PRs es "tremendamente eficiente hasta el momento del merge", resaltando la capacidad de avanzar en paralelo sin bloqueos.

Modular, en el anuncio de su herramienta stack-pr, destacó tres beneficios estructurales:

Revisiones más rápidas: PRs pequeños se revisan en minutos, no en días. Un PR de 200 líneas tiene una tasa de aprobación mucho mayor que uno de 2.000.
Historia de código más limpia: Cada PR refleja una unidad lógica de trabajo, lo que facilita el debugging y la auditoría futura.
Desarrollo sin bloqueos: El desarrollador avanza en PR #3 mientras el revisor procesa PR #1. El cuello de botella desaparece.

Los problemas reales que debes conocer antes de adoptarlo

No todo es positivo. El mismo Dave Pacheco advierte que el mayor riesgo de los stacked PRs está en el momento del merge: si cambias algo en un PR intermedio de la pila, todos los PRs superiores se rompen y requieren un rebase manual individual.

Otras limitaciones documentadas:

Curva de aprendizaje alta para equipos acostumbrados al modelo de un solo PR por feature.
Sincronización compleja post-squash: reconciliar la historia después de un squash merge puede ser tedioso.
Documentación mayoritariamente en inglés, lo que representa una barrera real para equipos en LATAM y España que no tienen inglés técnico fluido.

La herramienta gestiona automáticamente los rebases en cascada, lo que mitiga el principal problema, pero el flujo mental de entender una pila de 5 PRs sigue siendo más complejo que un PR simple.

¿Qué significa esto para tu startup?

Si tu startup tiene un equipo de desarrollo de más de 2 personas, los stacked PRs pueden cambiar radicalmente tu velocidad de entrega. Aquí las acciones concretas que puedes implementar esta semana:

Evalúa el tamaño promedio de tus PRs actuales. Si supera las 400 líneas de código, tienes un problema de revisión que los stacked PRs pueden resolver. Herramientas como Graphite Metrics o los propios insights de GitHub te dan este dato en minutos.
Instala gh stack y prueba con un PR real. No necesitas cambiar todo el proceso de tu equipo. Empieza con una feature nueva, divídela en 3 PRs lógicos con gh stack new y observa el impacto en tiempo de revisión.
Define una convención de nombres para tu pila. Algo tan simple como feat/checkout-flow-1, feat/checkout-flow-2 reduce la confusión del equipo en la UI de GitHub mientras adoptan el nuevo flujo.
Establece un límite de tamaño de PR como política de equipo. Muchos equipos tech de alto rendimiento tienen reglas explícitas: ningún PR puede superar 300-500 líneas. Los stacked PRs te dan la herramienta técnica para cumplirlo.

Para startups en etapa temprana con un solo desarrollador, la propuesta de valor también aplica: dividir tu propio trabajo en piezas pequeñas te obliga a pensar con mayor claridad sobre las dependencias del código, y facilita que futuros colaboradores o inversores técnicos revisen tu historial.

El contexto más amplio: GitHub apuesta por el desarrollo incremental

El lanzamiento de GitHub Stacked PRs no es una feature aislada. Es parte de una tendencia más amplia en la industria hacia el trunk-based development y la entrega continua. Empresas como Google, Meta y Shopify llevan años usando variantes internas de stacked commits para mantener ciclos de entrega de horas, no semanas.

Al traer esta funcionalidad al mainstream con soporte nativo en GitHub, la plataforma está democratizando una práctica que antes requería herramientas de terceros, configuración avanzada o el uso de monorepos con sistemas propietarios.

Para el ecosistema hispanohablante, donde muchas startups operan con equipos pequeños y recursos limitados, adoptar prácticas de desarrollo de alta eficiencia sin costo adicional es una ventaja competitiva real.