Introducción a la CLI de GitButler

GGitButler
컴퓨터/소프트웨어창업/스타트업AI/미래기술

Transcript

00:00:00Hola a todos. Mi nombre es Scott Chacone y soy el director ejecutivo de Git Brother.
00:00:02Voy a hacer una demostración rápida de la nueva CLI de Git Brother.
00:00:06Así que, si están familiarizados con la línea de comandos,
00:00:08y quieren usar Git Brother de forma programática,
00:00:11la nueva interfaz de comandos es una herramienta genial.
00:00:14Empecemos. Muy bien, comenzaremos con un repositorio.
00:00:18Tengo este pequeño proyecto en Rust,
00:00:20y vamos a ver cómo funciona el flujo de trabajo con la CLI de Git Brother.
00:00:23Básicamente, es un reemplazo directo para Git. Una vez instalada,
00:00:27tienes el comando "but". Esta será tu interfaz principal en lugar de Git.
00:00:32Puedes ejecutar "but" o "but status", que es su forma abreviada.
00:00:35Y te mostrará el estado.
00:00:38Es muy similar al resultado de un "git status".
00:00:41Vemos que hay cuatro archivos modificados.
00:00:44Hay un par que no están rastreados y otros que han sido cambiados.
00:00:47Algunos archivos nuevos y otros modificados, pero en la salida de "but",
00:00:50el estado simplemente te mostrará una lista de cuatro cambios, ¿vale?
00:00:55Estas son las cosas que has modificado. Y puedes confirmarlas (commit)
00:00:59como prefieras. Lo que haremos es simplemente ejecutar "but commit".
00:01:02Esto creará una rama temporal. Vamos a probarlo.
00:01:05Si ejecutamos "but status" de nuevo, vemos que todos los cambios están agrupados.
00:01:11También podemos usar "but status -f" o "--files".
00:01:15Te mostrará los archivos que se han modificado en este commit.
00:01:18Pero supongamos que no queremos incluir todo en un solo commit,
00:01:21¿verdad? Algunos tienen que ver con Clod, otro es un readme,
00:01:24y otros son cambios reales al código. Son realmente tres cambios distintos,
00:01:28¿no? Así que queremos tres commits separados. Vamos a deshacerlo.
00:01:31Podemos anular un commit ejecutando
00:01:36"uncommit". Y ya estamos de vuelta. Aún tenemos esta rama temporal aquí.
00:01:40Podemos borrarla si queremos, pero vamos a reutilizarla.
00:01:44Voy a cambiarle el nombre; la llamaré "Clod stuff".
00:01:48Ahora tengo una rama nueva y puedo añadir archivos a ella,
00:01:53como un "git add". Podemos poner: "but stage G0" y "H0".
00:01:58Estos son los códigos cortos para los archivos.
00:02:01También podrías escribir la ruta completa si quisieras,
00:02:04pero intentamos que sea un proceso rápido. Si me fijo ahora,
00:02:08están en la etapa de preparación para la rama "Clod stuff" y puedo hacer commit con "-o",
00:02:12que significa "solo lo preparado". Si ejecuto "commit",
00:02:15confirmará todo lo que esté preparado y lo que no.
00:02:18Esto tendrá más sentido cuando tengamos más ramas,
00:02:20pero hagamos el commit. Ahora tenemos una rama con un commit
00:02:25y un par de cambios sin preparar.
00:02:28Aquí es donde se pone interesante porque, a diferencia de Git,
00:02:31digamos que quiero tomar este readme,
00:02:34hacer el commit, subirlo y abrir una solicitud de extracción (PR).
00:02:37Normalmente, si estoy en la rama de "Clod",
00:02:41tendría que guardar los cambios (stash), añadir el readme, hacer commit
00:02:44y subirlo para el pull request.
00:02:45Pero en Git Brother podemos tener ramas paralelas.
00:02:50Puedo poner "but branch new" como "readme" y verán que aparece una rama nueva
00:02:55que se desprende, y ahí puedo preparar ese archivo.
00:03:00Hago el commit del archivo.
00:03:01Si reviso los archivos modificados,
00:03:07tengo este commit con las dos cosas de Clod,
00:03:09y este con el cambio del readme. Una vez más,
00:03:11puedo hacer lo mismo. Puedo decir "commit -c",
00:03:17la "-c" es de crear, para crear una rama nueva así. Veamos,
00:03:21qué es lo que hemos cambiado realmente... se me olvidó. Ah,
00:03:25el comando "read". De acuerdo.
00:03:27Eso tomará lo último que no se haya confirmado
00:03:32y te permitirá crear una rama nueva para hacerle el commit.
00:03:35Ahora vemos que tenemos tres ramas.
00:03:38Son todas independientes entre sí.
00:03:39Y todos esos cambios siguen en nuestro directorio de trabajo.
00:03:42No hemos alterado nuestro directorio de trabajo en absoluto.
00:03:44Solo estamos creando commits en memoria.
00:03:46Ahora puedo ejecutar "but push" y me preguntará: "¿Qué quieres subir?".
00:03:50¿Quieres subir todas? Cada una tiene un commit pendiente de subir.
00:03:53¿O solo una? Subamos solo el readme.
00:03:57Digamos que es la única que creemos que está lista ahora mismo.
00:03:59La seleccionamos y se subirá.
00:04:02Y si volvemos a mirar el estado,
00:04:03veremos por el indicador que esta ya se ha subido.
00:04:06Y las otras solo están en local.
00:04:08Git Brother es muy potente para trabajar con varias ramas a la vez,
00:04:11pero también permite crear ramas apiladas (stacked branches).
00:04:13Veamos un ejemplo de cómo crear algo nuevo
00:04:17basado en uno de los commits que ya hemos hecho,
00:04:19creando una rama apilada sobre él.
00:04:20Así podemos fusionar la de abajo y seguir trabajando en la de arriba.
00:04:23Supongamos que queremos crear una rama apilada.
00:04:26Queremos que revisen y fusionen este comando "read",
00:04:30pero queremos seguir trabajando sobre él.
00:04:32Es el momento ideal para una rama apilada en lugar de una independiente,
00:04:35porque hay una dependencia. La forma de hacerlo es
00:04:38usar "but branch new -a" para indicar un punto de anclaje,
00:04:42que es este comando "SC read". Y lo llamaremos "SC read more".
00:04:46Si nos fijamos ahora,
00:04:48podemos ver que tenemos esta rama apilada encima.
00:04:50Vamos a editar esto.
00:04:52Vemos que toma 10 mensajes y los muestra.
00:04:57Cambiémoslo a 20 mensajes y ajustemos esto también.
00:05:02Vemos el cambio y aparece este icono de candado porque
00:05:09estamos modificando un archivo que ya confirmamos en otro sitio.
00:05:11Así que queda bloqueado a un commit específico.
00:05:13Solo podemos confirmarlo encima de este porque cambia código introducido ahí.
00:05:16Podemos ver los cambios con el comando "diff",
00:05:20que es una buena forma de ver qué fragmentos han cambiado, y procedemos
00:05:25a hacer el commit. Muy bien.
00:05:28Para ver lo fácil que es mover commits de un lado a otro,
00:05:32les mostraré qué hacer.
00:05:33Con "status -f" vemos todos los archivos.
00:05:37Vamos a compartir esto. Ya vimos "push",
00:05:40que sube al repositorio remoto que tengas,
00:05:42pero también tenemos "PR", que abre una solicitud de extracción. Decimos:
00:05:46"¿Para cuáles de estos queremos abrir un PR?"
00:05:48Vamos a abrirlos para todos.
00:05:50Se abrirá un editor para cada uno preguntando
00:05:54cuál quiero que sea la descripción. Lo haré sencillo.
00:05:57Y ya tenemos todos los PR. Ahora que están abiertos,
00:06:01podemos ver estos números arriba: el 1, el 2...
00:06:04son los números de PR y sus mensajes.
00:06:06Usamos los mismos cada vez.
00:06:08También podemos ver con el comando "-v" (de detallado)
00:06:10las URL de cada uno de ellos.
00:06:12Echemos un vistazo a uno.
00:06:14Este es el PR que cambia el readme; vemos que solo tiene
00:06:18un commit y solo el cambio de ese archivo. Está aislado.
00:06:23Este otro es el de la rama apilada.
00:06:24Y si lo miramos, vemos que lo que ha hecho
00:06:28es abrir una pila. El primero,
00:06:30que es el PR base, apunta a "main".
00:06:35Y el segundo, al que podemos saltar aquí, apunta al primero.
00:06:39Así que gestiona correctamente las ramas apiladas.
00:06:41Ahora veamos qué pasa cuando integramos algo.
00:06:43Vamos a este PR del readme. Decimos: "Vale,
00:06:46se ve bien. Voy a fusionarlo". Ahora ya está integrado arriba.
00:06:49Y si ejecutamos "but pull --check", hará la comprobación.
00:06:55También podemos usar "but fetch"; lo hará por nosotros.
00:06:57De hecho, hace búsquedas en segundo plano de vez en cuando.
00:07:00Quizás lo hayan visto al ejecutar otros comandos.
00:07:02Dice que inició una tarea en segundo plano, pero vemos que este se ha integrado.
00:07:06Se ve integrado en el remoto. Así que cuando ejecutamos "but pull",
00:07:10obtendrá la nueva información.
00:07:13Reorganizará (rebase) nuestras otras ramas y eliminará esta rama ya integrada.
00:07:16Vemos que se ha quitado de local.
00:07:19Así que esa ya está lista.
00:07:22Las otras se han actualizado y podemos volver a subirlas si queremos.
00:07:25En cualquier momento,
00:07:29si quieres volver a usar Git normal, puedes usar "but tear-down".
00:07:33Eso te pedirá elegir una de tus ramas.
00:07:36Verás que elegirá la primera rama en la que estabas,
00:07:39pero sigues teniendo todas las ramas en las que estuvimos trabajando.
00:07:43Es solo que Git solo puede estar en una, así que vuelves a estar en una sola.
00:07:47Puedes usar "setup" y "tear-down" para entrar y salir del modo Git Brother.
00:07:50Úsalo si quieres trabajar en varias ramas o simplemente con las herramientas de Git normales.
00:07:55Pero incluso en modo Git Brother, puedes usar la mayoría
00:08:00de comandos de Git. Puedes hacer "git show" en estos; es lo mismo.
00:08:04Puedes hacer "git log", funciona igual.
00:08:08Todos los comandos de lectura funcionan bien: show, log, todos.
00:08:13Lo que realmente gestionamos por ti son los commits. En este caso,
00:08:16también puedes cambiar de rama (checkout) directamente; Git Brother lo detectará
00:08:21y retirará todo lo que estaba haciendo. Y de nuevo,
00:08:24todo debería estar bien.
00:08:26Lo último que mostraré es que todos estos comandos tienen una versión JSON.
00:08:30Si quieres ejecutar "status" con "--json", puedes hacerlo.
00:08:34Si quieres ver un commit con ese formato, también.
00:08:41Casi todos los comandos tienen esa opción.
00:08:44Pueden verlos todos con "but help". Casi todos tienen
00:08:48el parámetro "--json" o "-j".
00:08:52Esto significa que puedes automatizarlos fácilmente. Incluso algo curioso:
00:08:56puedes hacer un "diff" y te da una versión JSON del mismo,
00:09:00lo cual me parece genial.
00:09:01Esta es una buena introducción a Git Brother y lo que ofrece frente a Git.
00:09:05Recuerda que puedes usarlo en cualquier repositorio de Git.
00:09:08Solo ejecuta "but setup" y empieza con los comandos.
00:09:12Tienes salidas JSON, gestión de múltiples ramas,
00:09:15ramas apiladas, e integración con GitHub
00:09:17para manejar tus PR.
00:09:20Todo es instalarlo y empezar a usar los comandos "but".
00:09:24Y cuando quieras volver a Git,
00:09:26aunque la mayoría de sus comandos siguen funcionando aquí,
00:09:29solo tienes que usar "tear-down" o cambiar de rama y se limpiará todo.
00:09:33Pruébalo hoy mismo.
00:09:35Ve a [gitbrother.com/cli](https://www.google.com/search?q=https://gitbrother.com/cli) para descargarlo y empezar a jugar con él.
00:09:39Pásate por nuestro Discord y cuéntame qué te parece. ¡Gracias!

Key Takeaway

GitButler CLI es una herramienta potente que moderniza el flujo de trabajo de Git al permitir la gestión simultánea de múltiples ramas y Pull Requests sin alterar el estado físico del directorio de trabajo.

Highlights

GitButler CLI funciona como un reemplazo directo de Git mediante el comando "but".

Permite trabajar con múltiples ramas en paralelo sin necesidad de usar stash o cambiar el directorio de trabajo.

Introduce el concepto de ramas apiladas (stacked branches) para gestionar dependencias de código complejas.

Ofrece integración nativa con GitHub para crear y gestionar Pull Requests directamente desde la terminal.

Todos los comandos admiten salida en formato JSON para facilitar la automatización y el uso programático.

Es compatible con los comandos de lectura de Git tradicional como log y show mientras está activo.

Timeline

Introducción y comandos básicos

Scott Chacone presenta la nueva interfaz de línea de comandos de GitButler diseñada para un uso programático y eficiente. Explica que el comando principal es "but", el cual sustituye las funciones habituales de Git para agilizar el flujo de trabajo. El comando "but status" muestra los cambios de forma simplificada, agrupando archivos modificados y nuevos de manera clara. El autor demuestra cómo realizar un commit inicial que genera una rama temporal automáticamente. Finalmente, se explica la función "uncommit" para deshacer cambios y volver al estado previo de los archivos.

Gestión de ramas paralelas y preparación de archivos

En esta sección se destaca la capacidad de GitButler para manejar varias ramas de forma simultánea en el mismo directorio. Chacone utiliza "but stage" con códigos cortos para preparar archivos específicos sin necesidad de escribir rutas completas. A diferencia de Git tradicional, el usuario puede crear una rama nueva para un archivo específico, como un readme, mientras mantiene otros cambios activos. Esta funcionalidad elimina la fricción de saltar entre ramas o usar el comando stash constantemente. El proceso permite que los commits se creen "en memoria" sin alterar los archivos físicos del proyecto de manera disruptiva.

Ramas apiladas y dependencias de código

El video profundiza en las "stacked branches" o ramas apiladas, una característica avanzada para organizar cambios dependientes. El presentador muestra cómo crear una rama nueva anclada a un commit existente mediante el parámetro "-a". Esto es ideal cuando se quiere seguir trabajando en una funcionalidad que depende de otra que aún está en revisión. GitButler utiliza un sistema de bloqueo visual para indicar que un archivo está vinculado a un commit específico de la pila. Se utiliza el comando "diff" para revisar los fragmentos de código antes de confirmar la nueva capa de cambios.

Integración con GitHub y Pull Requests

Se explica el proceso de subir cambios al servidor remoto y la gestión de Pull Requests (PR) mediante el comando "but PR". El sistema permite abrir múltiples solicitudes de extracción de forma masiva, solicitando una descripción para cada una en el editor. GitButler asigna números de referencia a los PR y permite ver las URL detalladas con el modo detallado "-v". La herramienta gestiona inteligentemente la base de cada PR, apuntando correctamente a "main" o a otra rama en caso de ser una pila. Esto facilita enormemente la revisión de código aislado aunque los cambios se hayan desarrollado en conjunto.

Sincronización, integración y limpieza

Chacone demuestra qué sucede cuando un Pull Request es aceptado y fusionado directamente en GitHub. Al ejecutar "but pull", la herramienta detecta la integración, realiza un rebase automático de las ramas restantes y elimina la rama local ya fusionada. Para los usuarios que deseen volver al flujo estándar de Git, el comando "but tear-down" restaura el estado normal de la terminal. Es importante notar que GitButler es consciente de los comandos de Git tradicional y se sincroniza si el usuario decide cambiar de rama manualmente. Esta flexibilidad permite alternar entre herramientas según la necesidad del desarrollador en cada momento.

Automatización con JSON y conclusión

Para finalizar, se resalta que casi todos los comandos de GitButler incluyen una opción para devolver resultados en formato JSON mediante el parámetro "-j". Esto incluye desde el estado del repositorio hasta las diferencias de código (diff), lo cual es fundamental para desarrolladores que buscan automatizar tareas. Scott invita a la audiencia a probar la herramienta descargándola desde el sitio web oficial de la CLI de GitButler. También anima a los usuarios a unirse a su comunidad en Discord para compartir comentarios y sugerencias. El video concluye enfatizando que la herramienta es compatible con cualquier repositorio Git existente mediante el comando "setup".

Community Posts

View all posts