El lanzamiento más importante de GitHub en años. PRs apiladas.
BBetter Stack
Computing/SoftwareInternet Technology
Transcript
00:00:00GitHub acaba de lanzar su mayor actualización en años: las PR apiladas, una nueva forma de dividir
00:00:05PR masivas en partes más manejables. En este video, veremos exactamente qué son
00:00:10y por qué deberías usarlas. Las PR apiladas son un concepto potente pero bastante sencillo. Permiten dividir grandes cambios
00:00:21de código en una cadena de pull requests dependientes más pequeñas que se pueden revisar y fusionar de forma independiente.
00:00:26Para tener una pila, necesitas dos o más pull requests en el mismo repositorio donde la primera
00:00:31o la pull request inferior apunta al tronco, normalmente la rama predeterminada de tu repositorio como main,
00:00:37y luego cada pull request posterior apunta a la anterior. Esto forma una cadena de dependencias donde
00:00:42cada rama se basa en la que está debajo. Los cambios fundamentales, como tipos compartidos o esquemas de bases de datos,
00:00:48van en las ramas inferiores, y el código que depende de ellos, como rutas de API y componentes de interfaz,
00:00:53va en las ramas superiores. Y quizás estés pensando: bueno, esto siempre lo he podido hacer, ¿verdad?
00:00:58Podía abrir una PR a main y luego otra PR a esa PR y encadenar tantas PR como quisiera.
00:01:04Y eso es totalmente cierto, porque en el contexto exclusivo de Git no existen las PR apiladas
00:01:09y seguirías simplemente conectando PRs en cadena. Solo dentro de GitHub es donde las PR apiladas
00:01:16cobran verdadero sentido. Pero aportan ventajas enormes. Y si quieres mantenerte al día
00:01:22con la tecnología y la IA, suscríbete a Better Stack. Para utilizar las PR apiladas, lo mejor es tener
00:01:27la CLI de GitHub instalada. Con ella, puedes ejecutar gh stack init y declarar tu nueva pila.
00:01:33Vayamos a nuestro editor de código para ver un ejemplo de cómo apilar múltiples PRs.
00:01:38Lo primero que haremos es ejecutar gh stack init setup database. En este caso,
00:01:44la PR o la rama se llamará setup database. Y esta será la PR base que ahora
00:01:50apuntará a main. Después podemos hacer nuestros cambios. Para esta demostración, solo añadiré
00:01:54cambios en el archivo readme. Indico que implementé la base de datos y luego haces git add,
00:01:59git commit. Todo aquí es Git estándar. Cuando estés listo para pasar a tu siguiente conjunto
00:02:04de cambios, puedes ejecutar gh stack add seguido de tu siguiente rama. Después hago más cambios,
00:02:10creo los endpoints de la API. Tal vez quiera añadir algunos puntos extra aquí, así que confirmo este cambio.
00:02:16Luego podemos añadir un segundo cambio y volver a confirmar. Como es de esperar,
00:02:20puedes hacer múltiples commits por rama. Y finalmente, ejecutaremos gh stack add setup front end,
00:02:25para hacer un cambio más aquí. De nuevo, hacemos git add y git commit. Una vez que estemos satisfechos
00:02:31con todos nuestros cambios y queramos subir todas esas ramas a GitHub al mismo tiempo,
00:02:36podemos ejecutar un solo comando: gh stack submit. Esto abrirá una mini interfaz de CLI donde podremos
00:02:42revisar cada una de las PRs de la pila y añadir un título y una descripción si lo deseamos. O podemos
00:02:48simplemente presionar siguiente en cada una y enviar tres PRs de una sola vez. Como puedes ver, las tres PRs,
00:02:55setup database, API y front end, se han subido a GitHub como una pila mediante un solo comando.
00:03:02Y en realidad puedes hacer todo esto sin la CLI de GitHub, siguiendo el método tradicional de
00:03:07vincular las PRs manualmente de main a PR1 y de PR1 a PR2. GitHub también las detectará como una pila
00:03:14una vez que las subas todas. La CLI simplemente facilita mucho su gestión. Recuerda que nada ha
00:03:20cambiado en Git en sí. Si quieres cambiar a una rama completamente distinta que no esté dentro de la
00:03:24pila en la que trabajas, puedes hacerlo y luego volver a la rama de la pila más tarde.
00:03:29Si vamos a GitHub, podemos ver cada una de nuestras tres PRs creadas
00:03:34como pull requests aquí. Y también verás un pequeño icono de pila que nos indica que estas
00:03:39PRs están asociadas a una pila. Si abrimos la PR superior, la que está en la cima de la pila, verás
00:03:45que abajo podemos hacer clic en merge stack y ver esta interfaz. Así podemos ver cada una de las
00:03:49PRs que forman parte de la pila. Podríamos revisarlas y aprobarlas una por una. Pero una vez conformes
00:03:54con todo, podemos hacer clic en merge stack y todas y cada una de esas PRs se fusionarán
00:03:59en main al mismo tiempo. También notarás que las referencias a las pilas están integradas
00:04:03en todo GitHub. Las verás en la página de pull requests, en la página de la lista de pull requests,
00:04:09en los workflows de GitHub y prácticamente en toda la aplicación.
00:04:14Así que si trabajas en PRs masivas y necesitas una forma fácil de dividirlas
00:04:18en segmentos separados, ya no tienes que esperar a que PRs independientes se fusionen en main
00:04:23ni hacer todo el rebase y la fusión por tu cuenta. Puedes crear una pila larga y GitHub
00:04:28está perfectamente equipado para gestionarlo todo desde la interfaz. Y la CLI es una forma estupenda
00:04:33de gestionarlo todo automáticamente. La respuesta online ha sido sumamente positiva
00:04:38y, sobre todo al usarla con IA, creo que puede ser una función muy potente
00:04:43cuando creas bucles agénticos y dejas que el agente trabaje durante horas. Ahora puede crear
00:04:48PRs apiladas y vincular todo ese trabajo en lugar de crear una PR masiva o montones
00:04:54de PRs completamente separadas. Espero que este video les haya sido útil, amigos. Díganme qué opinan
00:04:58de las PR apiladas en los comentarios y suscríbanse a Better Stack para estar al día con las últimas
00:05:02noticias de tecnología e IA. Gracias por ver y nos vemos la próxima.