Aprende Git como si fueras psicólogo

Ya sé, no soy muy original en el título. El fondo del asunto es que tras pelearnos con las bases de LaTeX la pregunta fue: «¿Y cómo haces para saber cuándo se ha cambiado algo y quién lo ha hecho si el trabajo es en equipo?» Mi respuesta es que no sólo cuando trabajo en equipo, también cuando trabajo solo, hay ocasiones en que es aconsejable llevar un control de los cambios que se hacen sobre un proyecto. Este mismo problema lo tienen los programadores en su trabajo y lo vienen resolviendo desde hace décadas con herramientas que se llaman control de versiones. De éstas, la que uso últimamente es Git, ─lo pronuncio como guit, con g suave─, que es uno de los más potentes, aunque tenga fama de difícil. También puedes utilizar fossil. Ambos dan para otro minicurso de los míos, pero quiero ser breve y ya he hablado en alguna ocasión de cómo uso git y lo puedes encontrar en el blog. Perdóname que no repita contenido. Lee este artículo, si estás interesado en git y después lee atentamente los que te recomiendo a continuación. El objetivo de este artículo no es que aprendas a manejar un control de versiones como un profesional, sino que sepas que existen este tipo de programas y que también hay entornos gráficos para ellos.

Para comenzar, es recomendable encontrar la información previa en el blog. Puedes encontrar otros artículos míos sobre git aquí y te recomiendo comenzar por éste primero:

https://notxor.nueva-actitud.org/2017/11/14/como-estoy-utilizando-git.html

Como verás, es una herramienta muy potente pero algo compleja de manejar, la curva de aprendizaje es empinada y puede jugar en nuestra contra el miedo a cargarnos algo. Olvídate de ese miedo, los controles de versiones se crearon precisamente para no perder nada de información. ¿Qué es lo que debemos aprender primero? ¿Por dónde empezamos y de qué hilos hemos de ir tirando? Os voy a contar un secreto: La línea de comandos es tu amiga. Pero entiendo que muchos de vosotros no habéis abierto una consola en vuestra vida. En este artículo trataré sobre herramientas gráficas para gestionar git... pero no explicaré en profundidad qué es ni cómo funciona. Es más, básicamente sólo te voy a hablar por encima de dos entornos gráficos que ya vienen con git.

Lo primero que debemos aprender es que git organiza repositorios, que a falta de mejor nombre, consisten en una serie de instantáneas del estado de los ficheros de un directorio. Puedes imaginar que git es una cámara fotográfica y que cada vez que le haces una foto¹ a tu directorio congelas su estado y podrás siempre volver a verlo en ese estado, como cuando miras una foto de esas en las que aún tenías pelo. Por otro lado, git también organiza ese álbum de fotos y nos permite visualizar cada una de esas fotografías organizándolas en distintos grupos² con sus separadores (ramas) para que no se mezclen ni se líe todo. También puedes trastear con las instantáneas y mezclarlas (merge), pegar parte de una en otra o cambiar entre carpetas (checkout), cambiarles el fondo (rebase), etc.

Viendo un repositorio podemos, por tanto ver claramente cómo ha ido evolucionando nuestro proyecto, desde el principio hasta el estado actual. Podemos situarnos en cualquiera de las instantáneas y ver cómo estaba el proyecto cuando se hizo esa foto.

No quiero repetirme y te invito a que leas los artículos que ya escribí sobre git en su día. Pero sé lo que estás pensando: ¿sólo línea de comandos? Sí, bueno, la herramienta es de línea de comandos y siempre es bueno conocerlos, sobre todo para tener más claro cómo funcionan los mismos, pero hay herramientas gráficas para manejar los repositorios. Si necesitas un entorno gráfico para manejar git³ puedes encontrar muchos hechos para esa tarea, simplemente haciendo una búsqueda por Internet. Además, algunos editores traen consigo algún plugin o herramienta para hacerlo gráficamente también. Como ya sabéis yo utilizo Emacs y éste tiene magit.

Pero seguramente, no necesitarás instalar ninguna herramienta extra, pues git viene con su propia interface gráfica y no sólo una ... puede que incluso tengamos dos ya instaladas con la aplicación:

• git gui
• gitk

El primer comando lanza el GUI que sirve para controlar repositorios, haciéndoles fotos, subiendo, bajando y sincronizando la información que contienen los diversos repositorios, etc. El segundo es un visualizador de commits, que nos los lista gráficamente y nos permite ver fácilmente qué se cambió, cuándo y quién lo hizo.

Si abrimos el primero veremos una ventana similar a la siguiente:

Desde esa ventana podemos crear un repositorio nuevo, podemos abrir uno ya creado, bien clonándolo desde algún sitio, o bien yendo a su directorio donde abrirlo. Vale, esa no es la ventana de trabajo, sólo una que nos muestra cuando lanzamos git gui estando en un directorio donde no existe un repositorio, lo que suele ocurrir cuando lanzamos el programa desde algún menú de aplicaciones. Si estamos utilizando una consola en un directorio que ya es un repositorio y lo llamamos, entiende que queremos abrir ese repositorio y nos muestra directamente la ventana de trabajo:

Como no hay cambios en el repositorio, los espacios aparecen vacíos y puede parecer una interface un poco sosa. Sin embargo, cuando hayamos cambiado algo nos encontraremos enseguida que nos muestra en el panel superior izquierdo los cambios marcados como unstaged. En el panel superior derecho nos mostrará el contenido de hayamos seleccionado a la izquierda. El panel inferior izquierdo nos muestra las etiquetas de los cambios marcados como staged y el panel inferior derecho es un espacio para escribir el mensaje o comentario del commit⁴.

Es decir, esta herramienta nos permite modificar el estado de un repositorio en general. La ventana de trabajo está enfocada a los commit que son los cambios más habituales del mismo, pero también nos permitirá gestionar los distintos repositorios remotos que debe sincronizar, las ramas del mismo y otra serie de acciones que representan un cambio de estado para el proyecto.

Muy bonito lo de las fotos pero: ¿Cómo podemos recorrer nuestro álbum? Supongo que a estas alturas te preguntarás que aunque de todas formas los proyectos avanzan siempre hacia adelante, te gustaría poder ver qué se cambió, quién lo hizo y cuándo se compartió el cambio y tener algún tipo de histórico del mismo.

Para eso podemos utilizar el otro programa que mencionamos antes: gitk... de hecho lo podemos lanzar desde el mismo git gui en el menú: Repository > Visualize master's History.

También encontrarás, que es posible hacerlo al revés y lanzar git gui desde la ventana de gitk con el menú Archivo > Start git gui. Para lanzar el programa desde una consola es siempre recomendable hacerlo con el comando:

gitk --all

Eso cargará todo el repositorio. Si no queremos cargarlo entero, con sus ramas y todos los commits (las fotos) desde el principio de los tiempos, podemos utilizar el comando gitk sin ninguna opción.

Pero bien, vamos a explicar un poco su interface. Como podemos apreciar en la imagen anterior, he hecho una captura del repositorio de este blog. Vemos que la parte superior de la ventana muestra una lista de fotos del repositorio. Coinciden con los artículos que he ido añadiendo y por tanto en los tres paneles todo es muy lineal: el comentario asociado al commit en el panel de la izquierda, el usuario que ha hecho los cambios (en este blog siempre yo) en el panel del centro y a la derecha la fecha y la hora de cuándo se hizo el cambio.

En la parte inferior nos muestra los datos asociados del commit que seleccionemos arriba. En la parte inferior izquierda podremos ver los cambios que se han hecho, a la derecha una lista de los ficheros que se han modificado.

Entre la parte superior e inferior hay una barra de datos que nos da información sobre el commit, como su etiqueta SHA1 que es única y también podemos buscar entre todos los commits con distintas opciones.