Consejos y trucos de Git

• Hay muchas funciones menos conocidas que incluso quienes llevan años usando Git pueden pasar por alto, lo que cuestiona la suposición de que el conocimiento avanzado de la línea de comandos ya es común
• A diferencia de la generación que migró desde SVN o CVS, los desarrolladores que solo han usado Git tuvieron menos oportunidades de aprender algunos usos avanzados
• Con el tiempo, Git ha seguido agregando funciones pequeñas pero útiles, y estos cambios pueden tener valor práctico en situaciones específicas
• Para usuarios intermedios a avanzados, la serie divide en 3 artículos breves funciones antiguas pero útiles, funciones agregadas recientemente y temas sobre repositorios grandes y monorepos
• Revisar funciones que no se ven usando solo los hábitos familiares de Git puede ayudar a manejar de forma más eficiente el trabajo cotidiano con repositorios

---

Por qué vale la pena volver a mirar Git

• En presentaciones recientes sobre Git y GitButler, se confirmó que muchos desarrolladores tienen muchas lagunas de conocimiento sobre Git
• Antes se daban presentaciones avanzadas sobre Git, pero durante aproximadamente los últimos 10 años se asumió que la gente ya conocía las funciones avanzadas de la línea de comandos
• La generación de desarrolladores que solo ha usado Git no tuvo que migrar desde herramientas como SVN o CVS a Git, ni reaprender conceptos anteriores
• Git también ha aprendido funciones nuevas con el tiempo y, aunque la mayoría son cambios sutiles o pensados para usos específicos, pueden ayudar en el trabajo real
• La serie del blog se basa en la presentación de FOSDEM 2024 little known Git stuff

Serie de consejos de Git dividida en 3 partes

• Está dirigida a usuarios intermedios a avanzados de Git y cubre funciones que podrían haberse pasado por alto incluso después de usar Git durante mucho tiempo
• En lugar de reunirlo todo en un solo artículo, se organiza en 3 artículos breves con algunos temas cada uno
• Temas incluidos:
  • Oldies but Goodies: funciones de Git antiguas pero todavía útiles
  • Some Subtle New Things: cambios sutiles agregados recientemente a Git
  • Really Large Repositories and Monorepos: contenido relacionado con repositorios muy grandes y monorepos
• El primer artículo continúa con Oldies but Goodies

[GN⁺]

Opiniones de Hacker News

• Como autor, admito que aprendí una buena parte de esto apenas hace relativamente poco. Las funciones relacionadas con repositorios grandes son cosas que Microsoft y GitHub han ido incorporando poco a poco al core de Git durante los últimos años, así que ha sido difícil encontrar un recurso que reúna en un solo lugar lo que han hecho
  También tuve conversaciones interesantes con gente del lado de Mercurial, y dicen que recientemente han obtenido mejoras sorprendentes de velocidad al escribir parte del interior de Hg en Rust
  También estoy pensando en una 3.ª edición de Pro Git, así que si hay cosas que hayan descubierto al aprender Git por las malas, o que quisieran saber, me gustaría que me las contaran
  • Tal vez ya lo sepan, pero difftastic va muy bien como reemplazo del diff de Git: https://difftastic.wilfred.me.uk/
    Como alias frecuentes en gitconfig, uso fza, gone y root. git fza muestra archivos modificados/nuevos en una ventana de fzf y pasa el archivo seleccionado a git add: https://github.com/junegunn/fzf
    git gone elimina ramas locales que ya no existen en el remoto, y git root imprime la raíz del repositorio, así que sirve para volver a la raíz desde un directorio profundo. Últimamente lo uso menos porque uso zoxide: https://github.com/ajeetdsouza/zoxide
  • En la parte sobre diferencias de espacios en blanco, también estaría bien incluir ignore-revs-file. Se hace commit de un archivo de ignore-revs en el repositorio, y quien haga un gran reformateo agrega ese SHA para que git blame no se arruine
    https://git-scm.com/docs/git-blame#Documentation/git-blame.txt---ignore-revltrevgt
  • Una de las cosas que más me costó aprender en Git es que operaciones como merge, cherry-pick y rebase no funcionan sobre snapshots, sino sobre diferencias y parches, o más precisamente, sobre merge de tres vías. Pro Git enfatiza muy bien el modelo de almacenamiento por snapshots de Git, pero si uno piensa solo en ese modelo, puede confundirse, sobre todo con rebase
    Por ejemplo, no entendía por qué durante un rebase, con solo borrar un commit, terminaban cambiando todos los commits posteriores. Solo cuando entendí que el almacenamiento es basado en snapshots pero las operaciones son basadas en diferencias, logré entender rebase, y creo que enfatizar más esa parte también ayudaría al enseñar
• No quiero aprender trucos de Git, quiero usarlo de la forma más simple posible. Solo quiero hacer push del código, terminar con Git y seguir trabajando
  Respeto a la gente a la que le gusta Git, pero para mí es solo una herramienta que tengo que usar
  • Parte de la complejidad de Git viene de que originalmente fue diseñado como plumbing de bajo nivel. La idea era que sobre el modelo de datos de Git se construyera una capa más amigable para el usuario, así que incluso hoy esa dirección podría ser la mejor forma de conseguir una UI simple y consistente. Jujutsu y Got(game of trees) podrían ser ejemplos de eso
  • Entiendo ese sentimiento, pero Git tampoco es tan difícil. Más allá de lo básico como checkout/commit/push, aprender algunas cosas —sobre todo reescritura del historial— puede mejorar muchísimo la calidad del historial de commits y hacer que a otros ingenieros del proyecto les resulte más fácil entender el flujo
    Git parece ser casi una constante duradera en la industria, y como es una de las herramientas que más se toca en el desarrollo diario, vale la pena dedicarle un poco de atención
  • Hay detalles que son inherentes al problema en sí y otros que no. Creo que tendemos a subestimar la dificultad inherente
    Por eso me parece bien que haya cierto grado de complejidad en Git
  • Suena parecido a decir que no quieres aprender programación y que quieres usar la computadora de la forma más simple posible. Como si solo quisieras decirle qué hacer y listo
  • La interfaz de Git se siente como una abstracción con fugas. No quería aprender trucos de Git, pero al final terminé sabiendo más de lo que quería
• Recién aprendí sobre core.fsmonitor. Desde la perspectiva de un monorepo grande, ojalá git clone tuviera una opción para reanudar
  En los 2000 intenté clonar el repositorio del kernel con una conexión de poco ancho de banda y tuve el mismo problema; después de pedir ayuda en la lista de correo, alguien terminó subiendo el repositorio completo como tar comprimido a un sitio personal para que pudiera descargarlo
  Incluso ahora, si el VPN de la empresa se corta un momento, a veces me pasa lo mismo al clonar repositorios grandes. Imaginen recibir el 95% de un repositorio de Windows de 300 GB y que el wifi se corte por un instante
  Es raro que Git y Docker, dos de las herramientas que más ancho de banda consumen en el stack moderno de desarrollo, no soporten bien la reanudación de descargas
  • Lo que quieres se parece más a git bundle. Aunque claro, con la condición de que alguien tenga que crear el bundle en primer lugar
    https://git-scm.com/docs/git-bundle
  • Tal vez se pueda haciendo un clone superficial y luego expandiéndolo varias veces. Aun así, el protocolo de fetch/push en esencia asume repositorios más pequeños, o conexiones a internet y servidores muy buenos
• Muy interesante. Me gustaría ver quién puede resolver con una interfaz más sencilla el problema de que varias personas contribuyan a distintos releases, features y hotfixes, etiquetar releases y volver al pasado para buscar bugs
  Es parecido a pedir un lenguaje de bajo nivel que oculte la complejidad del sistema; en la práctica, las dos cosas casi se excluyen mutuamente. Git es satisfactorio y no es tan difícil de aprender, así que en parte simplemente hay que aprender Git
  • Por eso termino recomendando mucho GitKraken. Me cuesta porque es un producto de pago, pero probé varias herramientas y no encontré ninguna que liberara tanto su poder como GitKraken
    Quita esa sensación de caja negra que muchos desarrolladores tienen en la terminal y pone el grafo al frente, además de mostrar visualmente el trabajo de rebase de una manera intuitiva, haciendo que Git se vuelva divertido
    La soltura con la CLI sigue teniendo valor, pero ver a desarrolladores con 10 años de experiencia trabarse resolviendo problemas básicos, o arruinar el historial del proyecto por el ambiente de “si eres un ingeniero de verdad, solo debes usar la CLI de Git”, resulta frustrante
    Hoy en día, incluso si usas la CLI, les digo que tengan el grafo abierto en otra ventana todo el día. Se puede hacer gratis con VS Code, JetBrains e incluso desde la CLI

Cuando un miembro del equipo fusiona un PR, lo reviso de inmediato y hago rebase de mi rama, así que la rama siempre se mantiene actualizada sobre main y así evito el infierno de los merges o dejar commits horribles de “fix conflicts”

• Mientras buscaba los 10 archivos con más modificaciones desde que se crearon ayer, encontré https://github.com/tj/git-extras/blob/main/Commands.md
  Tiene muchos comandos adicionales de Git que valen la pena

  • git-extras está bueno. Otra herramienta bastante buena es git absorb: https://github.com/tummychow/git-absorb

• No entiendo muy bien por qué la mayoría de los desarrolladores se empeña en usar Git CLI cuando clientes de UI modernos como GitKraken son suficientemente útiles y ayudan bastante: https://www.gitkraken.com/

  • Saber CLI lleva a escribir scripts, y lo que aprendes de Git en scripts luego vuelve a servir en el uso diario. No quiero quedarme inútil solo porque al entrar por SSH a una Raspberry Pi que uso como servidor tenga que usar la CLI
    No estoy totalmente en contra de las GUI, pero por ahora la CLI es más eficiente y no quiero gastar tiempo buscando una GUI que cumpla estas condiciones
    Que se vea bien, que sea una app nativa y no una especie de navegador web viejo metido a la fuerza, que no tenga telemetría o que venga desactivada por defecto, que sea completamente open source y que pueda esperar que no desaparezca dentro de 5 años
    Además, no debe hacer todo más confuso. En una empresa anterior tenía que usar Visual Studio, y había un botón que de forma inquietante decía “Accept merge”, cuando en realidad quería decir “marcar como resuelto el conflicto”
    No debería confundir a gente que ya espera que ciertas palabras tengan ciertos significados, y también cuesta confiar en comportamientos como un botón de “Commit changes” que, en nombre de ser amigable, hasta hace push al remoto
  • La CLI también es perfectamente usable. También uso plugins del editor, pero si ya estoy en la línea de comandos, lo hago ahí mismo
    Si para hacer un commit tengo que cambiar a otro programa, se me quitan las ganas de hacer commits con frecuencia
  • A menos que haya un problema muy específico, minimizo lo que hago con Git. En mi caso, en la práctica es push, pull y checkout, así que usar una GUI me parece excesivo
  • Se ve limpio, pero una interfaz gráfica se vuelve demasiado distractora con mucha facilidad. Al final parece ser una cuestión de preferencia personal, y la CLI es rápida pero tiene una curva de aprendizaje alta
    Incluso cuando uso Git desde la CLI, la mayoría del tiempo no hago nada especial, solo unos pocos comandos, y los tips o trucos que no uso seguido los dejo anotados en un archivo de texto

• Conocía -committerdate, pero no sabía que podía configurarse como orden predeterminado, y es muy útil. Tengo algunas notas
  git columns se vuelve bastante confuso si no cabe completo en pantalla y hay que hacer scroll, así que estaría bueno que tuviera números
  git maintenance se ve bien, pero me preocupa porque hago mucho rebase. Me pregunto si hace que se pierdan objetos sueltos más rápido que gc. Veo que gc está desactivado, pero no queda del todo claro
  En cuanto a git blame, hay un script poco conocido pero útil: https://github.com/gnddev/git-blameall. Era tan poco conocido que tuve que portarlo yo mismo a Python 3, y ni siquiera soy desarrollador de Python

  • En el mantenimiento programado, gc está desactivado. Cuando ejecutas explícitamente maintenance run, se activa como tarea
    No recolecta los objetos sueltos más rápido que gc. Al final simplemente ejecuta gc
  • Me pregunto si se puede ordenar en reversa. Una solución simple al problema de que las ramas se salgan de la pantalla parece ser dejar las ramas más recientes al final. Yo lo hago con un script de usuario
  • No se pierden más rápido. Solo trae datos del remoto con más frecuencia y vuelve a empaquetar los datos. Si GC está desactivado, los datos no se eliminan
    git-blameall se ve bien, así que debería probarlo

• Simplifiqué mucho mi flujo de Git con unos alias que funcionan en varios entornos
  git synced sincroniza la rama actual con su upstream si existe, o si no con origin, usando rebase. Usa master o main, dando prioridad a main
git pub publica los cambios en el origin remoto usando force push con lease
  git pr abre la URL adecuada del PR en GitHub y no requiere el cliente GH. Si hay un upstream definido, manda el PR hacia allá
  git hub abre la página de GitHub del repositorio
  https://softwaredoug.com/blog/2022/11/09/idiot-proof-git-aliases.html

  • Me pregunto por qué eligió esa extraña flecha peluda como separador

• Dejé de fingir que sé lo que hago y uso herramientas visuales de Git, como SmartGit o las que vienen en IntelliJ. Los “héroes de la línea de comandos” de Git me parecen más postureo que otra cosa
  La capa de comandos orientada al usuario puede ser desesperantemente confusa. Por ejemplo, Yours y Theirs pueden significar exactamente lo contrario según el contexto
  Como no hay un estilo o tema común en toda la interfaz de usuario, hace falta una nueva capa visual para no volver loca a la gente

  • Igual aquí. Siempre puedo ver las diferencias y confirmar visualmente de un vistazo qué va a pasar. Tampoco hace falta ejecutar varios comandos adicionales
    Solo conozco la app y Git en general hasta el punto necesario para el trabajo, y si rara vez necesito más, lo busco. En varios años de uso eso me pasó una o dos veces
  • Para el trabajo diario siempre uso una herramienta visual de Git, en especial Tortoise Git
    Incluso para tareas complejas de corregir errores de otros o míos, primero reviso el historial, los commits, el reflog y las diferencias con una herramienta visual para entender qué se rompió y si hay algo rescatable
    Si solo tengo que volver a un commit, hago reset --hard; si tengo que combinar algo de varios commits, normalmente uso la línea de comandos

• Ambos no son mutuamente excluyentes. Para cosas como diffs o conflictos uso solo herramientas visuales, pero aprendí mucho al entender los objetos de commit, el reflog, lo que hace rebase por detrás, el rebase interactivo y los resets hard/soft.