Guido Torres

Mi camino con GIT y sus herramientas

Antes que nada voy a aclarar que no soy un experto en GIT ni mucho menos. De hecho tengo varios recursos para buscar cuando meto la pata fuerte y si todo falla no dudo en recurrir a la vieja y conocida "detonar el proyecto y clonarlo de nuevo". Si eso no deja en claro que aún sigo en camino de aprendizaje no sé qué lo va a hacer.

tldr de la nota: Si te intimida GIT y la terminal empezá sin dudas por Github Desktop u otra GUI de GIT, no está mal ni vas a ser peor dev por eso. El aprendizaje es un proceso relativo y muy personal. Está buenísimo conocer las distintas herramientas y variantes posibles que existen y te sirvan para la etapa en la que te encuentres.

Habiendo dicho eso:

Primera etapa: Pánico

Desde que tengo recuerdo la terminal es esa cosa mística en la cual si bien aprendí a usar algunos comandos básicos no iba mucho más lejos. Al día de hoy tampoco tengo mucha más necesidad que esos comandos, pero eso es otro tema

Un día entré al mundo de web development, me enteré de esa cosa extraña llamada repositorios y un amigo sugirió empezar a usar GIT y subir a un repositorio lo que vaya haciendo. Internamente fue un "LOQUE?" . Genial (pensé iluso) después de tirar unas líneas de HTML y CSS, creyendo que ésto otro iba a ser igual de amoroso. Después de leer un par de artículos y entender poco y nada, me embarqué a hacer un repositorio y subirlo usando GIT a GitHub. Ese primer repositorio lo terminé chocando absolutamente al punto de que en su momento no supe como recuperarlo, no entendía que estaba haciendo, entré en pánico, borré toda la carpeta .git, busqué una herramienta gráfica y le esquivé fuertísimo a GIT por un buen tiempo.

Mi comienzo profesional en el rubro fue freelance. En esa modalidad de trabajo nunca tuve necesidad de usar GIT más que para hacer tracking/historial del código con commits y push a master así como venía, por lo que dependía pura y exclusivamente de interfaces gráficas, particularmente Github Desktop (GHD de acá en adelante)

Github Desktop Dato: se puede usar para repos de otros sitios por fuera de Github, cosa que no supe por un tiempo porque tampoco usaba otra cosa que no fuera Github🤦‍♂️

Recomiendo fuerte usar ésta herramienta si al comenzar no te "emociona" particularmente ponerte a usar la terminal o simplemente no te sentís comodx. A mi me ayudó un montón y no me arrepiento en absoluto. Algunos pros:

  • La interfaz gráfica es altamente amigable
  • Tiene muchos warnings de cuestiones que uno al principio no considera o ignora por completo y te va guiando
  • Te marca la estructura y flujo de como funciona GIT de manera gráfica (Título de commit, descripción, commit en sí, cambios en archivos, push, pull...)
  • Te incita a experimentar de forma menos intimidante con operaciones "complejas" (branching, merges, rebases )
  • Y una de las más importantes: te introduce en el mundo de repositorios remotos y las operaciones que los acompañan (Clone, Forks, remotes, PRs...)

Segunda Etapa: Familiarización

Ya entrado en éste ciclo tenía mi flujo armado; Trabajo con el editor de texto, hago commits y manejo el estado del repositorio desde GHD, nada podía malir sal.

GIT, donde nada puede malir sal

Empecé a trabajar en una empresa como dev, colaborando en equipos y de la mano de eso vinieron 2 cuestiones:

  • Me di cuenta que me sentía terrible inútil por usar GDH en un ambiente donde todxs usaban la terminal. Tal vergüenza me daba al punto que evitaba mostrarlo y esquivaba situaciones donde tuviera que realizar operaciones de GIT frente a otra gente para no "fallar en público" (luego me amigue un poco más con la idea de chocar seguido y aprender de eso)
  • Empecé a necesitar realizar operaciones más complejas que un simple commit y push a master.

De la mano de las anteriores aparecieron otros nuevos problemas como merge conflicts, merging de branches, rebases, cherry picking y otras cosas que solamente ayudaron a que GIT me pareciera más intimidante de lo que ya me parecía.

Pero estaba determinado a salir adelante por lo cual me decidí a realizar todo lo posible desde GHD y desde la terminal únicamente lo que fuera absolutamente necesario.

En ésta etapa aparecieron 3 herramientas nuevas:

GitGraph vino a cubrir la necesidad de poder ver gráficamente el árbol de GIT desde el editor (herramienta que algunos editores traen de forma nativa, en repositorios remotos como GitLab también está y desde ya en git usando git log --graph --pretty pero que para ese momento ignoraba completamente). Una feature que siempre consideré necesaria para GHD siendo justamente un programa que se basa en tener una interfaz gráfica.

Gitlens es una herramienta que recién tiempo después aprendería a apreciar y en su momento no le encontré mucha utilidad. La mantuve deshabilitada (pero instalada) en el editor mucho tiempo más.

OhShitGit es una de esas que cada tanto reviso en cuanto me encuentro con algo y quiero una respuesta rápida que sepa que probablemente pueda encontrar ahí. Es un machete online de algunos comandos para ciertas situaciones cuando uno la 💩 como bien dice el nombre.

Por último LearnGitBranching es un recurso para aprender GIT que me parece obligatorio de al menos revisar, bien ejemplificado, algunas cosas rara vez las vas a usar en tu día a día pero que son importantes de conocer mínimamente que existen.

En ésta instancia me amigué con el flujo de trabajo remoto y otras operaciones que se volvieron parte del día a día (pull, push, clones, merges, resolver conflicts, en ciertas ocasiones realizar cherry picking o retroceder en el árbol de commits, etc). Nuevamente mérito a LearnGitBranching que fue una gran ayuda.

Tercera etapa: Ok quizás la terminal está buena

De a poco empecé a usar la terminal integrada de VS Code con Bash como shell y me fuí familiarizando con la sintaxis de la cual me venía protegiendo GHD todo éste tiempo. A medida que pasaba el tiempo y con mucha repetición en el día a día, ésta cosa intimidante se volvió rutinaria al punto que ya me empezó a molestar tener que realizar ida y vuelta entre editor y GHD.

(Acá meto un paréntesis porque le empecé a dar bola a Gitlens que es una terrible herramienta que hoy en día mantengo activa. No sólamente por el Git Blame interactivo (te permite ver quién escribió/editó cada línea y cuándo) sino porque es un intermedio entre interfaz gráfica y terminal integrado en tu editor. No es todo divino y hermoso pero te ahorra parte de lo tedioso de estar escribiendo ciertos comandos o haciendo algunos procesos embolantes. Extensión recomendadísima y sé que tiene mucho más para explorar de lo que uso actualmente)

Así seguí un buen tiempo, hasta que me aburrí de encontrarme cambiando de proyectos y tener que matar el servidor del primero, abrir el segundo e inicializar el mismo para hacer unos cambios y luego repetir todo de nuevo. En un día en el que tenés que hacer ida y vuelta constante se vuelve tedioso muy rápido. Por otra parte Bash por fuera de la integración con VSCode me resultaba bastante feo e incómodo por lo que empecé a buscar alternativas.

Disclaimer: Uso windows como OS, planeo migrar a Linux pero aún realizo cosas de mi profesión anterior que requiere soft que no corre en linux y la realidad no necesito mucho más de lo que tengo en Win, asi que por el momento sigo tirando. Haters vengan de a 1000.

Rápidamente encontré emuladores de terminales linux (porque Powershell jamás 🙅‍♂️) que me permitían usar comandos de Linux estando en W10. Entre las opciones disponibles las más potables que probé fueron:

Honestamente las primeras 2 si bien son altamente configurables no las recomiendo, dejan bastante que desear por más que estéticamente son mejores que bash pelado, pero tardan en cargar, a veces se cuelgan y otras cuestiones que a mi me terminaron cansando rápido.

Pasadas éstas 2, encontré Windows Terminal que es la que uso al día de hoy y se la recomiendo fuerte a cualquiera que desarrolle en Windows.

Microsoft Terminal

  • Es rápida (más rápida que las otras al menos, no voy a entrar a comprar con otros OS porque seguro que en Linux u otro anda todo más rápido y bonito)
  • Tiene tabs, themes (a lo VS Code) y otros ajustes estéticos y gilada que a mi me encantan
  • Es altamente configurable a través de un .json que se edita desde VSCode mismo y te permite agregar themes y los hotkeys que quieras que no sean standard.
  • Te permite correr el shell que quieras, como la terminal integrada de VSCode pero en una ventana aparte, por lo que ya no tengo que cerrar ningún servidor si tengo que hacer un cambio rápido de proyecto o si me veo forzado a matar VSCode. Ésto significa que es posible tener un tab con CMD, otro con Powershell, Bash y más todos corriendo en paralelo.
  • Es un proyecto Open Source con el cual se puede colaborar y al cual se le pueden hacer requests de features y mejoras.
  • A pesar de estar en desarrollo es muy estable y realmente no tuve problemas de performance en absoluto.
  • No tiene boludeces que no vayas a usar, lo cual aprecio muchísimo. Creo que de las pocas opciones que vienen en la UI uso todas y el resto se configura a gusto de c/u.

Al día de hoy creo que ya está en versión 1.x estable, mejor aún

Cuarta etapa: Performance, customización y vagancia

Ya estando cómodo con las herramientas y más confiado con el manejo de terminal comenzó nuevamente a picarme la curiosidad y la vagancia para poder ahorrarme el tener que tipear a mano comandos de git que realmente son un garrón.

Un día me crucé con una nota de Sarah Drasner (si no la tienen, seguirla urgente) en la que cuenta como configurar Bash para usar aliases en comandos de GIT y entré en mi vicio favorito al día de hoy, convertir todo a aliases.

Git Aliases

En resumen el alias es hacer tu propio comando bajo el nombre que quieras para ahorrarte de tipear todo cada vez. Bien usado es magia.

Recomiendo empezar con algunos pocos aliases simples y luego escalar porque podés terminar con 200 aliases y no estar ni enterado de qué hace cada uno. En cuanto a la nomenclatura yo soy partidario de que tenga sentido para uno, hay varias convenciones ya estipuladas (OhMyZsh por ejemplo ya trae un listado gigante de aliases en el plugin de GIT) que varios usan pero prioridad que unx esté conforme. Yo me encontré re-escribiendo varios a lo que a mi me queda bien o me suena natural.

En mi experiencia es un camino de ida y se alínea mucho con mi manera de pensar el usar aliases pero entiendo que puede que no a cualquiera le resulte.

Para ir cerrando y pensando en retrospectiva:

  • Git está bueno, es una gran herramienta (aunque tiene sus problemas como todo) y si bien puede resultar intimidante al principio, al día de hoy me resulta fascinante y el haber pasado por varias etapas de conocimiento y aprendizaje me hace apreciarlo aún más al entender un poco mejor el funcionamiento por detrás.
  • Es estúpido juzgar a alguien por una herramienta que usa mientras le funcione y esté cómodo (por más que haya otras más rápidas/eficientes/loquesea). Igual de estúpido o más es juzgarse unx mismx por eso. Si le pudiera hablar a mi yo pasado le diría que se relaje y use todo lo que necesite GHD o la herramienta que fuera.
  • No tirarse de cabeza a usar algo "porque es lo más pro" o cosas así. Aprender es un proceso muy personal, no todos tienen la misma velocidad, los mismos modos o paradigma mental. Habrá gente que le servirá sin tener conocmiento absoluto tirarse de cabeza hasta que les funcione. En mi caso me resultó mejor ésto de tener etapas entre herramientas acorde a mi progreso personal. Cada herramienta tiene su utilidad y su momento y unx se va dando cuenta cuando necesitá algo más o si lo que está usando le queda grande y necesitá ir a otra cosa, no hace falta apurarse.

De yapa dejo otro link a un sitio similar a OhShitGit pero más interactivo y amigable: Git Explorer

Te gustó? Seguime en twitter y comentame a ver si escribo sobre otros temas relacionados.