⏱️ Lectura: 10 min
GitHub abrió el 30 de julio de 2026 el preview público de los pull requests apilados (stacked pull requests) para todos los repositorios del servicio. La función parte un cambio grande en una serie ordenada de PRs chicos, cada uno enfocado en una capa puntual, y deja mergear todo el stack con un solo clic.
📑 En este artículo
El objetivo es simple: terminar con el PR de miles de líneas que nadie quiere revisar, sin obligar al equipo a manejar ramas manuales que hay que rebasear a mano cada vez que cambia una capa de abajo.
TL;DR
- GitHub lanzó el 30 de julio de 2026 el preview público de pull requests apilados para todos los repositorios.
- La función divide un cambio grande en una cadena ordenada de PRs, cada uno enfocado en una capa puntual.
- Cada PR de la cadena se revisa y se prueba por separado, con las branch protections de main sin cambios.
- Mergear la capa más avanzada aterriza esa capa y todas las de abajo en una sola operación.
- Se instala con
gh extension install github/gh-stackdesde la GitHub CLI. - Funciona desde github.com, la CLI, la app móvil de GitHub y agentes como Copilot con el gh-stack skill.
- El soporte de merge queue para stacks se despliega de forma progresiva en las próximas semanas.
- Tim Neutkens (Next.js, Vercel) y Andy Merryman (CTO, TED) confirman que ya usan stacks para acelerar revisiones.
Introducción
Los pull requests apilados describen un patrón que ya existía en herramientas externas, pero que ahora vive nativo dentro de GitHub. En vez de un único PR monolítico, el desarrollador arma una cadena de ramas: cada una construye sobre la anterior y se abre como un pull request independiente que apunta a la capa de abajo, no directo a main.
Cada PR de la cadena se revisa, se prueba y se aprueba por separado. Los checks existentes, las reviews obligatorias y las branch protections de main siguen aplicando sin cambios, según detalla el changelog oficial de GitHub.
Qué pasó
El anuncio llegó el 30 de julio de 2026 a través del changelog de GitHub, que confirma que la función se está desplegando “to all repositories over the coming days”. El soporte de merge queue para stacks avanza por separado, en un despliegue progresivo durante las próximas semanas.
Tim Neutkens, líder de Next.js en Vercel, contó que el equipo ya venía usando pull requests apilados desde hace meses: “It has helped us introduce smaller individual changes while shipping larger features, making it easier to review PRs”, según la cita que recoge GitHub en su changelog.
El flujo funciona igual desde github.com, la GitHub CLI, la app móvil de GitHub o un agente como GitHub Copilot usando el gh-stack skill. No hace falta un cliente distinto para cada capa del stack.
Contexto e historia
Dividir un cambio grande en una cadena de commits o ramas dependientes no es una idea nueva. Herramientas como Phabricator, usada internamente en Meta, o Graphite, una capa externa sobre Git y GitHub, popularizaron el flujo de “stacked diffs” entre equipos que priorizan revisiones chicas y frecuentes.
La diferencia con esta función es que ahora vive dentro de GitHub sin instalar un servicio externo ni pagar una herramienta de terceros. El stack se guarda como una secuencia normal de branches y pull requests: nada de metadata propietaria que solo entienda un cliente externo.
Antes de esta función, el problema práctico era el rebase manual: si el desarrollador tocaba la capa 1 del stack, tenía que actualizar a mano las capas 2 y 3 y volver a abrir cada PR. Con stacks nativos ese rebase y ese retargeteo son automáticos cuando se mergea una capa inferior.
Detalles técnicos y rendimiento
Cada pull request de un stack apunta a la capa de abajo en vez de apuntar directo a main. Al abrir cualquier PR de la cadena, GitHub muestra un “stack map” en la parte superior que ubica esa capa dentro del resto del cambio.
flowchart TD
A["PR 1: modelo de datos"] --> B["PR 2: endpoint /pagos"]
B --> C["PR 3: tests de integracion"]
C --> D[("main")]El mergeo funciona por capas: mergear el PR más avanzado que esté listo aterriza esa capa y todas las de abajo que sigan sin mergear, en una sola operación. Si el equipo solo mergea las capas inferiores, las de arriba quedan abiertas y se rebasean y retargetean solas contra la nueva base.
💭 Clave: las branch protections y los checks obligatorios de main siguen gobernando qué entra al repositorio: pull requests apilados no es un atajo para saltarse revisiones, solo cambia cómo se organizan.
Andy Merryman, CTO de TED, describió el problema que resuelve: “AI has made TED’s developers dramatically more productive, but that created a new bottleneck: PRs were growing large enough that reviewers were struggling. Stacked PRs help to solve that.” Con IA generando más código por desarrollador, el cuello de botella se movió de escribir código a revisarlo.
John Resig, creador de jQuery, resumió su experiencia con el flujo de merge queue: “Landing 5 stacked PRs directly to a merge queue all at once! A+++! This removes so much friction (and the gh cli tools + agent skill help a ton).”
| Interfaz | Cuándo usarla | Ventaja | Limitación |
|---|---|---|---|
| github.com | Revisar y aprobar capas sin salir del navegador | Stack map visual integrado en cada PR | Crear ramas nuevas sigue siendo manual desde la web |
| GitHub CLI (gh-stack) | Crear y reordenar el stack desde la terminal | Automatiza branch, push y apertura de PR por capa | Requiere instalar la extensión aparte |
| App móvil de GitHub | Aprobar o comentar una capa puntual desde el teléfono | Notificaciones por capa, no por PR gigante | No pensada para crear el stack, solo para revisarlo |
| Copilot con gh-stack skill | Delegar a un agente la creación de un stack completo | El agente arma las capas siguiendo el mismo flujo de la CLI | Depende de que el agente tenga el skill instalado |
Cómo empezar
Para crear el primer stack hace falta la GitHub CLI (gh) y la extensión gh-stack. La instalación de gh cambia según el sistema operativo:
# macOS (Homebrew)
brew install gh
# Windows (winget)
winget install --id GitHub.cli
# Linux (Debian/Ubuntu, via apt)
type -p curl >/dev/null || sudo apt install curl -y
curl -fsSL https://cli.github.com/packages/githubcli-archive-keyring.gpg | sudo dd of=/usr/share/keyrings/githubcli-archive-keyring.gpg
sudo apt update
sudo apt install gh -yCon gh instalado, el siguiente paso es agregar la extensión oficial. El comando es igual en macOS, Windows y Linux:
gh extension install github/gh-stackDespués, un flujo típico para armar un stack de dos capas sobre un repo llamado api-pagos se ve así:
# Capa 1: agrega el modelo de datos
git checkout -b feature/pagos-modelo
git commit -am "agrega modelo Payment y migracion"
gh stack push
# Capa 2: agrega el endpoint que usa el modelo de arriba
git checkout -b feature/pagos-endpoint
git commit -am "agrega POST /pagos usando el modelo Payment"
gh stack pushCada gh stack push abre o actualiza el PR de esa capa apuntando a la rama de abajo. Para confirmar que la extensión quedó instalada, corré gh extension list y buscá github/gh-stack en el resultado.
Impacto y análisis
El caso de TED ilustra el impacto más citado en el anuncio: equipos que ya escriben más código por persona gracias a asistentes de IA, pero cuyo cuello de botella se movió a la revisión humana. Dividir el cambio en capas no reduce el código escrito, pero sí el tamaño de cada diff que un humano tiene que leer de una sentada.
Para equipos en Latinoamérica que ya usan la GitHub CLI para automatizar releases o issues, sumar gh-stack no agrega infraestructura nueva: es una extensión más sobre la misma herramienta que probablemente ya corre en el pipeline de CI.
💡 Tip: si el equipo ya usa merge queue en main, conviene esperar a que termine el despliegue progresivo de esa integración antes de mover stacks grandes a producción, porque todavía se está expandiendo por semanas.
La limitación real está en la coordinación: si una capa de abajo cambia mucho después de que las de arriba ya se revisaron, el equipo tiene que volver a revisar lo que quedó afectado, aunque el rebase técnico sea automático. Pull requests apilados no resuelve un cambio mal planificado desde el inicio, solo el de un cambio bien planificado pero mal empaquetado en un PR único.
Qué sigue
GitHub confirma que el despliegue a todos los repositorios sigue en curso durante los próximos días, y que el soporte de merge queue para stacks se expande de forma progresiva en las próximas semanas. La documentación oficial y un canal de discusión sobre stacks quedan abiertos para feedback de la comunidad, según el changelog.
No hay fecha pública de disponibilidad general todavía; por ahora la función sigue en preview público, lo que en GitHub suele implicar cambios de comportamiento antes de estabilizarse.
Probalo vos: instalá la extensión con gh extension install github/gh-stack y armá tu primer stack de dos PRs sobre un repositorio de prueba hoy mismo.
📖 Resumen en Telegram: Ver resumen
Preguntas frecuentes
¿Qué son los pull requests apilados en GitHub?
Es una serie ordenada de pull requests donde cada uno representa una capa enfocada de un cambio más grande. Cada capa apunta a la rama de la capa anterior en vez de apuntar directo a main, y se revisa por separado.
¿Necesito pagar algo extra para usar pull requests apilados?
El changelog de GitHub no menciona un costo adicional: la función se describe como parte del preview público que se despliega a todos los repositorios.
¿Cómo se revisa cada capa de un stack?
Abriendo el PR de esa capa específica, que muestra solo el diff correspondiente a esa capa junto con un stack map que ubica dónde encaja dentro del resto del cambio.
¿Qué pasa con las branch protections de main?
Siguen aplicando sin cambios. Los checks requeridos y las reviews obligatorias sobre main gobiernan qué capas pueden aterrizar, igual que con un PR tradicional.
¿Cuándo llega el soporte de merge queue para stacks?
GitHub lo describe como un despliegue progresivo durante las próximas semanas, separado del resto de la función que ya está en preview público.
¿Puedo usar stacks sin la GitHub CLI?
Sí. El flujo funciona desde github.com, la app móvil de GitHub y agentes como GitHub Copilot con el gh-stack skill, además de la CLI.
Referencias
- GitHub Changelog: anuncio oficial del preview público de pull requests apilados, con las citas de Tim Neutkens, John Resig, Andy Merryman y Mayank Saini.
- GitHub Docs: documentación general de pull requests, revisiones y branch protections en GitHub.
- GitHub CLI: sitio oficial de la herramienta de línea de comandos que soporta extensiones como gh-stack.
- github/cli: repositorio oficial de la GitHub CLI, base para instalar extensiones como gh-stack.
📱 ¿Te gusta este contenido? Únete a nuestro canal de Telegram @programacion donde publicamos a diario lo más relevante de tecnología, IA y desarrollo. Resúmenes rápidos, contenido fresco todos los días.
Imagen destacada: Foto de Ferenc Almasi en Unsplash
0 Comentarios