Git, el sistema de gestión de código fuente descentralizado (Vol.2)

Una vez más aquí. En este artículo vamos a continuar hablando sobre el sistema de gestión de código fuente descentralizado llamado git.

En el anterior artículo terminamos viendo cómo podemos crear un repositorio desde nuestro equipo Ubuntu. Por lo que si quieres seguir este artículo que estoy escribiendo, deberías echar antes un vistazo a aquel artículo para crear tu repositorio git.

Añadir ficheros a tu repositorio

En el anterior artículo, como decía, creamos un directorio para nuestro repositorio. Ahora vamos a añadir el fichero README.md, que es un fichero de texto para la ayuda.

Para crear este fichero podemos utilizar un editor de texto a nuestro gusto. En mi caso yo utilizo Vim. Y dentro tan solo tendremos que escribir algo que creamos que puede resultar de ayuda a los usuarios.

Una vez creado el archivo y guardado dentro de la carpeta de nuestro repositorio, vamos a volver a la terminal.

En este momento el fichero README.md está en estado unstaged, que quiere decir que no está bajo control. El primer paso para meterlo bajo el control de versiones vamos a escribir en la terminal (Ctrl+Alt+T) el comando:

git add README.md

Con la orden add, se pueden indicar tanto archivos y directorios como nos haga falta como incluso utilizar comodines del estilo:

git add *.js

Además, también podemos indicar que se incluya absolutamente todo lo que hay en el directorio actual, incluyendo subdirectorios utilizando el comando:

git add .

Ahora el siguiente paso lógico será confirmar el cambio o hacer commit, pero antes veremos cómo comprobar el estado de la rama.

Estado de la rama (status)

El comando git status nos va a dar información acerca de la rama. Hay que decir que si no hubiésemos ejecutado el git add anterior, el resultado sería diferentes. Pero como lo utilizamos, veremos algo como lo siguiente:

Veremos que el fichero está listo para la confirmación, en estado staged. Tal y como nos indica git, si quisiésemos sacar ese fichero de ese estado, por no queremos confirmarlo todavía, se puede ejecutar el siguiente comando:

git rm --cached README.md

Commits

Llegados a este punto, es la hora de hacer commit, es decir, confirmar los cambios. En un proyecto gestionado por git cada vez que hacemos un commit, se están guardando los cambios del código y asignando un identificador único. Este es un mecanismo que permite crear puntos de control para la gestión de los cambios.

Para esto, vamos a utiliziar el comando git commit acompañado de la opción -m, indicando un texto que explique los cambios. El ejemplo de nuestro archivo README.md sería el siguiente:

git commit -m "Añadido el archivo README.md"

La pregunta que los usuarios pueden estar haciéndose es ¿cada cuanto hacer un commit? Existen diferente criterios y siempre dependerá del tipo de proyecto (personal o en equipo). Ni que decir tiene que no se debería hacer un commit a cada linea cambiada, ni hacer un commit que contenga infinidad de cambios, como un proyecto entero. Quizás la forma más razonable sería establecer un tamaño de commit que se puede resumir en la frase de commit.

Historial, git log

Siempre resulta importante poder ver los cambios efectuados en el repositorio existente, y estos podremos verlos con el comando git log:

git log

Nuevos cambios, con git diff

Llegados a este punto, ya podemos realizar una pequeña prueba. Para este ejemplo vamos a empezar por realizar algunos cambios en el archivo README.md que tenemos alojado en nuestro equipo.

Al hacer los cambios sobre este archivo después de realizar el último commit, git detectará la diferencia. Estas diferencias pueden consultarse con el comando git diff, que nos mostrará las líneas afectadas:

git diff

Revertir cambios con git checkout

Si realizamos cambios sobre un archivo, en este ejemplo README.md, que está bajo control de versiones pero que no queremos guardar, podemos utilizar el comando:

git checkout README.md

O bien se puede recuperar todo utilizando el punto al final del comando en lugar del nombre del archivo:

git checkout .

Confirmarlo todo

Para confirmar los cambios sobre todos los archivos que ya están bajo control de versiones, bastaría con escribir un comando como:

git commit -a -m "Cambios en README.md"

Mostrar commits

Conforme se van acumulando los commits, se pueden utilizar otras variantes para mostrar el historial, como por ejemplo –graph. Por el momento en el ejemplo sobre el que estamos trabajando, solo hay una rama, pero en proyectos complejos con diversas ramificaciones, esta posiblemente sea la mejor de las opciones.

git log --graph

También se puede obtener este mismo resultando, solo que de forma más abreviada utilizando el comando:

git log --graph --pretty=oneline

Ignorar archivos

Es importante tener claro que no se debe, aun que podamos hacerlo, meter cualquier elemento del proyecto en un control de versiones de código fuente. Dependiendo del tipo de proyecto, hay archivos que es mejor no incluir, como por ejemplo:

• Programa ejecutables, binarios, código compilado o resultados de build.
• Archivos objeto intermedios como los *.o de C.
• Librerías.
• Archivo temporales no imprescindibles
• Archivos de configuración que pudiese contener claves.

Si los subimos, aun que después los eliminemos, estos se quedarán en el historial de control de versiones, por lo que el daño ya estará hecho.

Cada proyecto de git tiene sus características. En cualquier caso, git cuenta con un mecanismo que permite discriminar archivos y directorios para que no entren en control de versiones, salvo que se fuerce de forma explicita. Este forzado se consigue añadiendo a git add la opción -f.

Este mecanismo de discriminación es un archivo de texto que se sitúa en la raíz del proyecto, este se llama .gitignore. En el tendremos que incluir una lista (de un item por línea) de todo aquello que no queramos que se incluya en el control de versiones.

.librerias/
temp/
config.txt

Hay que decir que el propio archivo .gitignore también se debe incluir bajo el control de versiones.

git add .gitignore
git commit -m Archivo gitignore añadido"

Según el tipo de proyecto que quieras desarrollar, el servicio de GitHub ofrece distintos archivo .gitignore con los contenidos más adecuados para cada sitio.

Eliminar archivos

Para eliminar un archivo del control de versiones, solo habrá que utilizar git rm nombre_del_archivo, y después habrá que hacer un commit como se muestra a continuación.

git rm nombre_del_archivo
git commit -m "archivo eliminado"

Recuperar borrados accidentalmente

Para este ejemplo vamos a suponer que eliminamos por error el archivo README.md.

Git nos va a permitir recuperarlo utilizando el comando git checkout. Para recuperarlo bastaría con utilizar el comando:

git checkout README.md

Y bueno, hasta aquí va a llegar el volumen 2 de esta pequeña guía sobre git. Próximamente llegará la tercera entrega en la que seguiremos viendo los entresijos de este sistema de gestión de código fuente descentralizado.