GitHub stacked PR: un diff pequeño no es una unidad de despliegue
Dividir un cambio en tres PR acorta la revisión. Si la superior depende de la inferior, eso no permite desplegarla por separado.
El anuncio del 6 de octubre
GitHub anunció la disponibilidad general el 6 de octubre de 2026. Las PR pequeñas pueden revisarse por separado y fusionarse juntas; están disponibles en todos los planes de github.com.
Una pila entra en la merge queue como un merge group. Con el método merge commit se crea un commit por PR. La unidad probada y la unidad del historial no son iguales.
Delimita la revisión
A podría añadir una función, B usarla en una API y C crear la interfaz. Documenta dependencias y base de comparación. Es una propuesta operativa, no una garantía automática del producto.
Leer solo B puede ocultar una autorización omitida en A. Separa la revisión del diff de la comprobación A+B+C y asigna un responsable de integración.
Qué significa una aprobación tras rebase
GitHub conserva las aprobaciones al rebasar una pila sin otros cambios después de que avance su base, incluso si el repositorio descarta aprobaciones antiguas. La aprobación y el resultado integrado son señales distintas.
Registra los SHA anteriores y posteriores y el merge group probado. Comprueba si se repitieron las pruebas y qué combinación cubren los registros; una marca verde aislada no basta.
Separa fusión y despliegue
Si función y API deben publicarse juntas, refleja la dependencia en el plan. Un commit por PR no garantiza que revertir uno solo sea seguro para los demás consumidores.
Los arreglos independientes no necesitan una pila. Agruparlos puede hacer que una prueba retrasada bloquee todo el conjunto; evalúa ese coste operativo.
GA no implica todos los controles hoy
GitHub anuncia el despliegue de auto-merge durante las próximas semanas. Verifica los controles reales del repositorio antes de asumir que todos los usuarios ven el mismo botón.
Los comentarios del preview motivaron mejoras de navegación y automatización. Son una señal de interés, no una garantía de productividad: mide tus tiempos de espera y fallos de integración.
Empieza con una pila pequeña
Prueba dos PR con dependencia clara, como función y consumidor. Anota base, dependencia y comandos de verificación; acuerda responsable y alcance del rollback antes de fusionar.
Compara la reducción de revisión con posibles fallos adicionales. Si mantener la pila cuesta más, vuelve a PR normales. La menor confusión importa más que la cantidad de diffs.
Fuentes oficiales
Anuncio del 6 de octubre; comprobado el 8 de octubre de 2026. Revisa reglas y funciones disponibles antes de adoptar el flujo.