Las PR apiladas ya están disponibles en GitHub
La nueva función de pull requests apiladas de GitHub, ahora en vista previa pública, busca ayudar a los desarrolladores a dividir cambios de código grandes en una serie de PR más pequeñas y dependientes que puedan revisarse y fusionarse con más facilidad. Muchos ingenieros celebran el soporte nativo para un flujo de trabajo que antes emulaban con herramientas de terceros o ramificación manual, y señalan beneficios para CI, el alcance de la revisión y el trabajo en paralelo. Otros sostienen que la función está incompleta, tiene errores o es redundante frente a commits bien estructurados, y algunos critican a GitHub por ignorar antecedentes en sistemas como Gerrit y Phabricator o por añadir otra capa de complejidad en lugar de mejorar las herramientas centrales de revisión.
Recepción general
- Muchos están entusiasmados; las PR apiladas se describen como uno de los cambios más grandes de GitHub en años y una función largamente ausente en comparación con otros sistemas.
- Otros se muestran poco impresionados y lo califican sobre todo como “azúcar de interfaz” sobre patrones que ya usaban (PR dirigidas a otras ramas de PR).
- Algunos creen que llega tarde y que para una v1 es algo básico/con errores; otros simplemente se alegran de que no sea otra función de IA.
Beneficios percibidos para el flujo de trabajo
- Permite dividir funciones grandes en unidades más pequeñas y revisables mientras el trabajo continúa en las partes posteriores.
- Habilita la revisión en paralelo: refactorización → backend → frontend, con distintos revisores por capa.
- Permite fusionar subconjuntos de una pila de funcionalidades (p. ej., infraestructura + API pero no UI) y ejecutar CI por unidad.
- La gestión de pilas (rebase automático de PR dependientes, fusionar-uno-o-fusionar-todo) se ve como una gran ventaja frente al rebase manual.
Críticas y limitaciones
- Algunos ven las PR apiladas como un parche para problemas de organización/revisión; sostienen que, en su lugar, se necesita mejor higiene de commits y PR más pequeñas e independientes.
- Hay preocupación de que el apilamiento aumente la complejidad, fomente ramas de larga duración y añada presión a los revisores (“cambiar la parte inferior de una pila de 5 niveles es doloroso”).
- La implementación actual tiene errores, especialmente en torno a la fusión squash de pilas y las interacciones con la cola de fusión; todavía faltan soporte entre repositorios y soporte completo para forks.
- Varios dicen que esto no resuelve las partes difíciles: reordenar trabajo local desordenado en series coherentes, verdaderas pilas entre repositorios o árboles/grafos de cambios dependientes.
Preocupaciones sobre revisión e interfaz
- La unidad de revisión de GitHub sigue siendo la PR; revisar commit por commit es incómodo y los comentarios no se mapean limpiamente a commits que evolucionan.
- Algunos desearían que GitHub hubiera adoptado un modelo de diff/serie de parches con IDs de cambio e interdiffs, como Gerrit/Phabricator y grandes forjas internas.
- La interfaz web para pilas se ve como mínima; los usuarios serios esperan depender de la CLI o de herramientas personalizadas.
IA y contexto más amplio
- Múltiples comentarios relacionan las PR apiladas con el crecimiento de diffs generados por IA y los flujos de trabajo de agentes, como una forma de mantener las revisiones a escala humana.
- Otros enfatizan que los flujos de trabajo apilados existen desde mucho antes de la IA; esta función principalmente lleva a la corriente principal una práctica ya establecida.