00:00:00Hola a todos, soy Scott, el CEO de GitButler.
00:00:02Hoy voy a mostrarles algunas de las funciones geniales de GitButler y darles
00:00:05una visión general de lo que este cliente de Git puede hacer.
00:00:07Tengo un proyecto de ejemplo aquí. Es un clon de Twitter o X; lo llamo "Y".
00:00:12Lo que voy a hacer es añadir algunas ediciones que ya realicé y vamos a ver
00:00:16cómo crear commits, ramas, ramas paralelas y cómo
00:00:20crear ramas apiladas. Si edito algunos archivos, verán algo
00:00:25similar a la salida de un "git status" que indica qué archivos
00:00:30han sido modificados en su directorio de trabajo. ¿Qué quieren hacer con ellos?
00:00:34¿Cómo quieren hacer el commit? Aquí podemos inspeccionarlos: mi CSS,
00:00:39el sidebar, el index... hay un par de cambios pequeños que hice aquí.
00:00:45Lo que quiero es crear una rama nueva y confirmar estos cambios en ella.
00:00:49Hay varias formas de hacerlo. Puedo pulsar en "commit to new branch"
00:00:54o crear explícitamente una rama independiente aquí; luego veremos el apilado.
00:00:57Le das un nombre, creas la rama y ahora hay varias opciones.
00:01:03Puedes simplemente hacer un commit; por ejemplo, de este archivo application.css,
00:01:08ya sea arrastrándolo al carril para crear el commit o iniciándolo desde aquí.
00:01:15Puedes escribir un mensaje de commit corto en este espacio pequeño o expandirlo
00:01:19para redactar un mensaje largo y detallado. Vamos a mantenerlo simple.
00:01:27También puedo decidir qué incluir en este commit. Tengo tres archivos al lado.
00:01:34No solo puedo descartar un archivo entero, sino entrar en él y elegir líneas específicas.
00:01:39Pero por ahora, hagamos el commit de todos los cambios aquí. O mejor,
00:01:44hagamos dos commits. No incluiré lo del sidebar en este; haré "front-end fixes"
00:01:48y luego otro commit de "sidebar fixes". Ahora tengo dos commits en esta rama.
00:01:55Como soy algo vago, usaré Claude para que haga este trabajo por mí. Voy a cambiar
00:01:59el tema de azul a rojo y luego intentaremos añadir una rama separada solo para eso,
00:02:04independiente de mis arreglos del front-end. Parece que ya está listo.
00:02:09Así se veía la web antes, como un pequeño Twitter. Si aplico los cambios,
00:02:14ahora tengo un bonito tema rojo y mis cambios de front-end están hechos.
00:02:18Y verán que estas son ramas independientes. Si desaplico el "front-end fixes",
00:02:25sigue estando en rojo. Esto es lo que hice aquí; puedo volver a ponerlo.
00:02:34O igual, puedo desaplicar el tema rojo y deja de ser rojo. Vamos a devolverlo.
00:02:43Ahora tenemos dos ramas distintas. Lo genial de esto es que si las subo
00:02:48a GitHub, los cambios están separados pero ambos se aplican simultáneamente.
00:02:52Es como las ramas de Git, pero puedes trabajar en varias a la vez.
00:02:57Si sigo trabajando en algo del sidebar, aparecerá aquí. Y puedo
00:03:04hacer varias cosas. Puedo arrastrarlo aquí y enmendar (amend) este commit,
00:03:10o puedo confirmarlo como un nuevo commit en esa rama. Tenemos dos ramas
00:03:14en paralelo. Veamos otra forma de hacerlo. Supongamos que
00:03:18el tema rojo depende de los cambios que hicimos en el front-end.
00:03:24Así que quiero fusionar lo del front-end antes de revisar lo del tema rojo.
00:03:29Vamos a deshacer este commit, lo anulamos y lo haremos como una rama apilada.
00:03:37Deshacemos el commit y desaplicamos el grupo. Ahora añadiremos una rama dependiente.
00:03:42Pulsas en crear nueva rama y eliges "dependent branch". También puedes
00:03:47hacer esto: crear una rama dependiente aquí y añadir el apilado de front-end.
00:03:51La llamaremos "sc_red_theme" y ahora pueden ver que estas ramas están apiladas.
00:03:58Ahora puedo confirmar el cambio en esta. Con las ramas apiladas,
00:04:06es muy fácil subirlas a GitHub. Si tienes la integración configurada,
00:04:11también puedes crear un Pull Request. Si creo un PR para el tema rojo,
00:04:16al ser una rama apilada, insertará una nota al pie en la descripción diciendo
00:04:20que esta rama depende de otra. Tendrás que fusionarlas todas juntas
00:04:25o fusionar "front-end fixes" antes que el tema rojo. Pero es una
00:04:30forma muy elegante de gestionar ramas apiladas. Si veo el PR ahora,
00:04:34enlaza ambas en una pila: esta es la parte dos y esta la parte uno,
00:04:39y dependen entre sí. Otra cosa genial es lo que llamamos
00:04:43asignación a ramas. En este caso tengo dos carriles y tres ramas.
00:04:48Dos están apiladas y una es independiente. Al empezar a hacer cambios,
00:04:54puedo asignar "hunks" o fragmentos de código a una rama específica.
00:05:00Es como si cada carril tuviera su propia área de preparación (staging) independiente.
00:05:05Es similar a "git add", pero con múltiples áreas de preparación independientes.
00:05:09Probémoslo. Añadiré una función nueva en la página de administración.
00:05:14La pondré en su propia rama, en el mismo directorio de trabajo,
00:05:19como algo independiente, y podré abrir un PR solo con esos cambios.
00:05:24Bien, este es el panel de administración antes. He hecho cambios,
00:05:31añadí registros recientes. Tengo estos dos cambios y quiero asignarlos
00:05:37a este carril. Si hago más cambios, se irán a "no asignados" si el sistema
00:05:43no está seguro; pero si están en los mismos fragmentos, se mantendrán asignados.
00:05:47Hagamos cambios en el controlador de administración. Un comentario tonto,
00:05:55pero veamos qué pasa. Como el controlador ya estaba asignado a este carril,
00:06:00no tengo que volver a prepararlo. El sistema entiende que esto es parte
00:06:05de ese cambio y lo incluye. Vamos a crear un commit para esto.
00:06:10Inicio el commit; puedo expandirlo para un mensaje detallado o usar la IA
00:06:15para generar el mensaje si necesito un punto de partida y luego editarlo.
00:06:19Analiza las diferencias que introduje y me da una base. Listo.
00:06:23Ahora tenemos un commit en la página de administración de registros. Tenemos
00:06:27la rama apilada al lado y puedo subir y crear un PR de esto de forma independiente.
00:06:31Si revisamos ese PR, veremos que aunque todos estos cambios
00:06:37están en mi directorio de trabajo a la vez, se han separado en
00:06:42ramas distintas. Así que puedo entrar y ver solo lo de administración.
00:06:48Claramente solo editó esas páginas y lo mantuvo en su propia rama y commit,
00:06:55sin mezclarse con el resto del trabajo de mi directorio. Están en ramas separadas.
00:06:58Esa es la ventaja de trabajar con ramas paralelas y apiladas en GitButler.
00:07:02Hay muchas cosas que serían difíciles en el Git normal y quiero mostrarles
00:07:06un par. Primero, podemos mover commits de una rama a otra.
00:07:11Si quisiera mover este commit de registros a la rama del tema rojo,
00:07:15solo tengo que arrastrar y soltar, y luego puedo eliminar la otra pila.
00:07:20Ahora mi commit está aquí. Si quiero combinar (squash) commits,
00:07:26puedo arrastrarlo no solo al de abajo, sino a cualquier otro de la pila.
00:07:30Puedo bajar lo de administración a "sidebar fixes" o incluso moverlo,
00:07:36ya sea más abajo en la pila o fusionándolo con otro commit.
00:07:41Y ahora ven que lo de administración también está en "sidebar fixes".
00:07:47También podemos hacer lo contrario: dividir un commit añadiendo
00:07:52un commit vacío y moviendo cambios hacia él. Si hago esto,
00:07:58puedo insertar un commit vacío en la pila. Puedo escribir el mensaje
00:08:02ahora o mover los archivos primero. Veamos los archivos.
00:08:08Tenemos el controlador y lo del sidebar. Arrastraré el "admin index" al medio.
00:08:13Ahora este commit solo tiene ese archivo; "sidebar fixes" aún tiene el resto,
00:08:20el controlador y el sidebar. También puedo mover solo fragmentos (hunks).
00:08:30Así, uno tiene parte de los arreglos y el otro tiene la otra parte.
00:08:34Y si quiero, puedo cambiar el mensaje del commit después.
00:08:41Esto nos lleva a que editar mensajes es muy fácil. Además de reordenar,
00:08:46combinar o dividir, puedo simplemente cambiar el nombre a "parte dos"
00:08:53y el sistema hará el rebase de todos los commits superiores automáticamente.
00:08:57Otra función interesante es editar commits directamente. Digamos que
00:09:01alguien me sugiere cambiar un margen de 0 a 10 píxeles.
00:09:06¿Cómo editamos un commit que está cuatro posiciones atrás y en otra pila?
00:09:13Con GitButler es muy sencillo. Vamos a realizar ese cambio.
00:09:16Aquí está, lo cambiamos a 10 píxeles. El CSS en línea es lo mejor. Este es
00:09:23el cambio. Está bloqueado porque editamos un fragmento ya modificado,
00:09:28así que debe ir en esta rama. No podíamos ponerlo en una rama paralela.
00:09:32¿Pero cómo lo incluimos? La forma más fácil es tomar este archivo
00:09:39y arrastrarlo directamente al commit deseado. Ahora, ese commit
00:09:46ya tiene los 10 píxeles y hemos rebasado el resto de la pila encima.
00:09:51La otra forma, como ya vimos, es crear un commit temporal
00:09:55y luego simplemente combinarlo (squash) con el anterior.
00:10:02Hace básicamente lo mismo; si comprobamos, el margen ahora es de 10 píxeles.
00:10:07Y la última forma interesante de hacer esto es con el "modo edición".
00:10:12Imaginemos que no hemos hecho nada aún y queremos cambiar esos 0 píxeles.
00:10:20Podemos ir al commit específico y seleccionar "edit commit".
00:10:25Esto hace algo curioso, parecido a un "detached head checkout" en Git.
00:10:30Básicamente te sitúa en ese commit exacto. Lo editas como quieras y,
00:10:36al salir, rebasará todo lo demás encima. Hacemos el cambio,
00:10:39el sistema detecta que el archivo ha sido modificado, guardamos y salimos.
00:10:46De nuevo, hace el rebase y el cambio queda guardado ahí.
00:10:52Puedes editar un commit directamente, hacer el cambio y enmendarlo,
00:10:57o hacer un commit y combinarlo. Hay muchas formas de manipular los cambios.
00:11:01Por último, les mostraré lo que llamamos el historial de operaciones.
00:11:05Esto es muy difícil de hacer en Git si alguna vez han usado el "reflog".
00:11:10A todos nos da un poco de miedo, pero todo lo que haces en GitButler
00:11:15se guarda en un log de operaciones y puedes volver a cualquier punto del pasado.
00:11:21Es este botón de aquí; vemos nuestro historial con todas las acciones
00:11:26realizadas durante la sesión. Y puedo retroceder a cualquier momento.
00:11:30Si quisiera volver a antes de empezar con lo de los 10 píxeles,
00:11:37podría regresar aquí y ver exactamente cómo estaba todo
00:11:42justo antes de ese cambio. O incluso volver al mismísimo inicio
00:11:47de esta sesión. Lo que no deshace es lo que ya se subió a GitHub.
00:11:52Aquí veo los commits subidos; aparecen como commits remotos (upstream),
00:11:56pero estoy volviendo a antes de haber confirmado absolutamente nada.
00:12:01Incluso puedo borrar la rama y empezar de cero si quiero, no importa.
00:12:05Incluso ese "deshacer" puedo deshacerlo. Si revierto la captura (snapshot),
00:12:11volvemos a donde estábamos. Siempre podemos viajar en el tiempo.
00:12:16Es genial porque nunca tienes que temer a ninguna de estas acciones.
00:12:22Si acabas en un estado extraño o quieres volver a como estaba hace 10 minutos,
00:12:26abres la línea de tiempo, das a revertir y listo. Esta fue una visión rápida
00:12:32de GitButler: rebasador, editor de commits, ramas paralelas y apiladas,
00:12:36todo fácil y sin herramientas extra. Descárguenlo, cuéntennos en Discord
00:12:41qué les parece y disfrútenlo.