Pro Git es un libro de Scott Chacon y Ben Straub. Tiene 2 ediciones. La primera es del 2009 y la segunda del 2014. La segunda edición aporta más información y dedica un capítulo entero a Github. Terminé de leer las dos hace algunas semanas y cambié por completo mi forma de utilizar Git como ya comenté anteriormente.
Mi primer control de versiones fue Netbeans y su sistema de copias de seguridad del cual podías configurar la antigüedad. En aquel momento, era más que suficiente para mi hasta que conocí Subversion.
Cuando estaba en Atallos Cloud, empezamos a utilizar Subversion junto con Dropbox y a pesar de tener algunos problemas de inconsistencias en ocasiones, sobre todo cuando hacíamos commit al mismo tiempo, nos fue bastante útil.
En las empresas -salvo la última- en las que trabajé, nunca hemos usado ningún control de versiones. Ahí empezamos con Subversion pero un día alguien decidió que debíamos utilizar Git. Estábamos cansados de los tiempos de descarga y subida de Subversion. El primer día que utilizamos Git nos quedamos alucinados con la velocidad. Podías hacer commit justo antes de marcharte a casa, no tardaba nada. Durante mucho tiempo, a eso se redujo Git, antes de irte, hacías git commit -a -m «blablabla…» y git push.
A pesar de utilizarlo durante varios años, nunca me paré a pensar cuál era la mejor manera de hacerlo o cómo funcionaba realmente. Add, commit, clone, push, init, pull, … y pocos más comandos más me sabía. No tenía ni tiempo ni ganas de aprender.
Afortunadamente, esto ya no es así y aunque de tiempo sigo limitado, ahora sí que tengo ganas. Me doy cuenta ahora de que no si no conoces las herramientas que utilizas estás perdiendo tiempo y energía. En el caso de Git, estaba utilizando un control de versiones pero en realidad no tenía mucha idea de qué estaba guardando, nunca había mirado el log de cambios y mucho menos restaurado una versión antigua. En realidad, utilizaba Git porque me había acostumbrado pero nunca fue parte de mi flujo de trabajo. Nunca lo he utilizado sabiendo conscientemente que en cualquier momento podría recuperar cualquier cosa que tuviera guardada. El ser consciente de este hecho me ha hecho utilizar Git ya no sólo en algunos proyectos sino en cualquiera por muy pequeña que fuera la incidencia y dejar de utilizar copias de seguridad manuales. Aún estoy lejos de ser un experto en Git, pero trabajo para conseguirlo.
Pro Git, Primera edición
No me extenderé mucho sobre las diferencias entre la primera y la segunda edición. Te recomiendo que te leas la segunda edición directamente. En mi caso, cometí un error al leer la primera edición. Llegué a la web y empecé a leer el contenido sin fijarme que existía una segunda edición. Cuando ya me había leído los 7 primeros capítulos, me di cuenta de ello pero decidí terminar de leerla igualmente. La segunda edición contiene lo mismo que la primera y más contenido por supuesto. Tiene un capítulo entero dedicado a github por ejemplo.
Pro Git, Segunda edición
El libro te cuenta cómo utilizar Git siendo un simple novato utilizando los comandos básicos hasta como utilizar los comandos llamados de «fontanería» internos y ocultos. A continuación, hablaré sobre algunos de los temas que trata el libro y me eran desconocidos.
Cómo funciona Git
La mayoría de control de versiones hasta la llegada de Git solía almacenar tus archivos y una lista de los cambios efectuados sobre cada archivo. Git, en cambio, almacena instantáneas de tus archivos cada vez que envías un commit. Si un archivo no ha sido modificado, no lo volverá a copiar, tan sólo enlazará con la versión anterior.
La primera vez que haces “git commit” te quedas impresionado por la velocidad. Si estás acostumbrando a Subversion, incluso llegas a sospechar de que no haya guardado nada. En realidad, cuando haces “git commit”, lo que haces es un guardado en tu repositorio local al contrario que Subversion con el cual estabas subiendo tus cambios al repositorio remoto.
Git es muy rápido porque la mayoría de las acciones son locales, se ejecutan sobre tu copia del repositorio que está en tu ordenador. Eso también te permite trabajar sin necesidad de estar conectado a internet. Puedes seguir enviando commits y cuando tengas conexión, subirlo todo al remoto.
Cada usuario de nuestro repositorio tiene una copia local. Eso significa que tenemos tantas copias como usuarios del repositorio y remotos. En mi caso, siempre trabajo con un sólo remoto, no he tenido ocasión de trabajar con más de uno. Si ese repositorio remoto fallara algún día, no habría problema ya que sólo tendría que subir mi repositorio local o el de otro usuario.
Rebase y Merge
Hasta hace poco, nunca había utilizado rebase. No había leído nada sobre ese comando y lo poco que había leído avisaba del peligro que suponía ese comando. Rebase significa reorganizar tu repositorio. La diferencia con merge es sencilla cuando la ves con imágenes como en este capítulo del libro.
Histórico de cambios: «git log»
Igual te parece raro pero pocas veces he utilizado el histórico de cambios de git. Las pocas veces que ejecuté “git log” en mi línea de comandos, me espantaban mis mensajes de commit. Ahora que he mejorado mis mensajes de commit, puedo echar un vistazo a mi histórico y entender cómo ha ido evolucionando mi proyecto.
Cuando envío un email a un cliente para informar de los avances en el proyecto o cuando subo algo a un servidor, utilizo “git log” para redactar el email. Puedo ver en ese histórico cada cambio que he realizado.
Me ha pasado muchas veces equivocarme al confirmar algo en el mensaje o incluso en el propio código. Descubrir que al final me faltan un par de líneas para que mi código sea completo. Esto acababa resultando en un histórico de cambios caótico. Ejemplo:
- Subida nueva cabecera web
- Arregla css del logo
- Añade css para versión tablet
- Soluciona error en móviles
Estos 4 commits deberían ser sólo 1 ya que en realidad se trata de la nueva cabecera, pero después de confirmar, me daba cuenta de algunos fallos y los iba solucionando. Para juntar estos 4 commits, debes usar rebase, pero si te das cuenta antes de confirmar que lo que vas a enviar pertenece al commit anterior, puedes utilizar “git commit —amend”. Esta simple instrucción te permite añadir, modificar y/o eliminar cambios de tu último commit.
Herramientas de Git
Git posee herramientas de las cuales no había oído hablar jamás.
Stash o la pila de guardado rápido
- “git stash” te permite almacenar tus cambios sin confirmarlos. Imagina que tienes que solucionar un error rápidamente, pero estás en medio de una modificación sin confirmar. Con git stash tu trabajo se guardará y git limpiará tu área de trabajo.
- “git stash apply” te permite recuperar tu trabajo. Este seguirá existiendo en la pila de guardados.
- “git stash drop” te permite eliminar algo de la pila de guardados.
- “git stash list” te permite ver lo que hay en esa pila.
- “git stash pop” te permite recuperar tu trabajo donde lo habías dejado y lo elimina de la pila.
- “git stash branch nombre_rama_nueva” te permite recuperar tu trabajo creando una nueva rama, poniéndolo en esa rama nueva y eliminándolo de la pila.
Bisect o hacer debug con Git
- “git bisect” te permite buscar donde has introducido un error en tu proyecto. Imagina que has estado trabajando durante un tiempo en tu proyecto y de repente descubres un error. Este error no ha sido introducido recientemente por lo tanto debes volver atrás buscando el lugar donde se introduce.
- “git bisect start” indica a git que vas a empezar a buscar el error.
- “git bisect bad” indica a git que el commit en el que estás ahora contiene el error.
- “git bisect good nombre_commit_correcto” indica a git el último commit conocido en el que el error no existía.
Git retrocederá hasta el commit que hay exactamente en la mitad de commits entre el erróneo y el correcto. Es decir si desde tu commit «good» al commit «bad» hay 12 commits, git te situará en el sexto. Tendrás que probar a ver si tu error está en este lugar. Si funciona, escribes “git bisect good” y git avanzará al siguiente commit que esté a la mitad de camino con el commit erróneo. Si el fallo ya estaba ahí, escribes “git bisect bad” y git seguirá retrocediendo.
Cuando hayas encontrado el error podrás salir del modo “debug” escribiendo “git bisect reset”.
Lectura obligatoria para TODOS los usuarios de Git
Diría que este libro debería ser obligatorio para cualquiera que quiera utilizar Git de forma seria. Este post sólo habla de algunas de las cosas que he descubierto pero el libro tiene mucha más información sobre cómo usar Git desde niveles muy básicos hasta niveles muy avanzados. Cualquier usuario novato o experto aprenderá algo seguramente leyendo Pro Git. Es una lectura imprescindible y además el libro es gratuito, ya no tienes excusa.
