Git tiene la posibilidad de marcar estados importantes en la vida de un repositorio, algo que se suele usar habitualmente para el manejo de las releases de un proyecto. A través del comando "git tag" podemos crear etiquetas, en una operación que se conoce comúnmente con el nombre de "tagging". Es una operativa que tiene muchas variantes y utilidades, nosotros veremos las más habituales que estamos seguros te agradará conocer.

Además de mantener informados a los usuarios del código de los proyectos y otros desarrolladores de las versiones de una aplicación, el etiquetado es una herramienta fundamental para que otros sistemas sepan cuándo un proyecto ha cambiado y se permitan desencadenar procesos a ejecutar cada vez que esto ocurre. De hecho es importante porque algunos gestores de paquetes te obligan a usarlo para poder publicar packages en ellos. Así pues, vamos a relatar las bases para trabajar con el sistema de tagging de modo que puedas usarlo en tu día a día en el trabajo con Git.

Numeración de las versiones

Git es un sistema de control de versiones. Por tanto permite mantener todos los estados por los que ha pasado cualquier de sus archivos. Cuando hablamos de Git tag no nos referimos a la versión de un archivo en particular, sino de todo el proyecto de manera global. Sirve para etiquetar con un tag el estado del repositorio completo, algo que se suele hacer cada vez que se libera una nueva versión del software.

Las versiones de los proyectos las define el desarrollador, pero no se recomienda crearlas de manera arbitraria. En realidad la recomendación sería darle un valor semántico. Esto no tiene nada que ver con Git, pero lo indicamos aquí porque es algo que consideramos interesante que sepas cuando empiezas a gestionar tus versiones en proyectos.

Generalmente los cambios se pueden dividir en tres niveles de "importancia": Mayor, menor y pequeño ajuste. Si tu versión de proyecto estaba en la 0.0.1 y haces un cambio que no altera la funcionalidad ni la interfaz de trabajo entonces lo adecuado es versionar tu aplicación como 0.0.2. Si el proyecto ya tiene alguna ampliación en funcionalidad, pero sigue manteniendo completa compatibilidad con la versión anterior, entonces tendremos que aumentar el número de enmedio, por ejemplo pasar de la 1.0.0 a la 1.1.0. Ahora bien, si los cambios introducidos en el proyecto son tales que impliquen una alteración sobre cómo se usará esa aplicación, haciendo que no sea completamente retrocompatible con versiones anteriores, entonces habría que aumentar en 1 la versión en su número más relevante, por ejemplo pasar de la 1.1.5 a la 2.0.0.

Realmente importa poco ahora el tema de la semántica, porque queremos hablar de Git. Sin embargo lo encuentras muy bien explicado en este documento Versionamiento Semántico 2.0.0-rc.2, por lo que, si te interesa el tema, te recomendamos leerlo.

Crear un tag con Git

Se supone que cuando comienzas con un repositorio no tienes ninguna numeración de versión y ningún tag, por lo que empezaremos viendo cómo se crean.

Supongamos que empezamos por el número de versión 0.0.1. Entonces para crear la correspondiente etiqueta lanzarás el subcomando de Git "git tag":

git tag v0.0.1 -m "Primera versión"

Como ves, es una manera de etiquetar estados del repositorio, en este caso para definir números de versión. Los acompañas con un mensaje, igual que se envían mensajes en el commit.

Generalmente, después de hacer cambios en tu repositorio y subirlos al sistema (después de hacer el commit), podrás generar otro número de versión etiquetando el estado actual.

git tag v0.0.2 -m "Segunda versión, cambios menores"

Ver los estados de versión en el repositorio con Git tag

Después de haber creado tu primer tag, podrás lanzar el comando "git tag", a secas, sin más parámetros, que te informará sobre las versiones que has etiquetado hasta el momento.

git tag

Si tienes un repositorio donde has etiquetado ya tres números de versiones, podría arrojar una salida como la que ves en la siguiente imagen.

Otro comando interesante en el tema de versionado es "show" que te permite ver cómo estaba el repositorio en cada estado que has etiquetado anteriormente, es decir, en cada versión.

git show v0.0.2

Recibirás como salida un mensaje parecido a este:

tag v0.0.2
Tagger: Miguel Angel Alvarez <malvarez@desarrolloweb.com>
Date:   Fri Nov 13 16:23:00 2015 -0200

"

commit 8ef366190b73d56e267c5324aa8074db3c3f0ed9
Author: Miguel Angel Alvarez <malvarez@desarrolloweb.com>
Date:   Fri Nov 13 16:21:54 2015 -0200

...

Enviar tags a GitHub

Si quieres que tus tags creados en local se puedan enviar al repositorio en GitHub, puedes lanzar el push con la opción --tags. Esto es una obligatoriedad, porque si no lo colocas, el comando push no va a enviar los nuevos tags creados.

git push --tags

En concreto la opción --tags, tal cual la hemos usado, envía todas las nuevas tag creadas, aunque podrías también enviar una en concreto mediante la especificación de la que quieres enviar, tal como se puede ver en el siguiente comando.

git push origin v0.0.4

En este caso debemos especificar qué repositorio remoto es el destino de las tags que acabamos de crear ("origin" en este caso), pues si no se especifica el comando entenderá que el nombre de nuestro tag es el nombre del repositorio remoto que estamos queriendo usar para enviar los cambios locales, lo que nos dará un error.

git push --tag

Enviar tags y hacer push de los commits al mismo tiempo

Solo un pequeño detalle relativo al comando push cuando lo usamos para enviar tags. Cuando en el comando push usamos la opción --tags en principio no se mandan los cambios que tengamos en el repostiorio. Es decir, aunque hayamos hecho cambios en la rama master y se hayan realizado los correspondientes commits en local, si lanzamos "git push --tags", únicamente los nuevos tags se van a enviar a remoto. No se enviarán los commits que se hayan podido realizar en cualquier rama.

Si queremos hacer un push de una rama en concreto, por ejemplo la rama master, y enviar los tags al mismo tiempo, entonces podríamos lanzar el siguiente comando.

git push origin master --tags

Conclusión Git Tag

Además, en el caso de GitHub también puedes crear tags en los repositorios directamente desde la interfaz web del servicio. Desde la página principal del repositorio, en el enlace que pone "releases", puedes acceder a la información sobre las versiones etiquetadas en tu proyecto, así como etiquetar nuevas versiones.

Hemos aprendido a etiquetar estados de un proyecto con Git, algo que se realiza comúnmente para informar en el sistema de control de versiones de las releases principales durante la vida de un software.

Trabajar con Git Tag como has visto no resulta nada complicado, puesto que en principio solamente son un par de comandos nuevos los que te tienes que aprender. Puedes obtener más ayuda sobre opciones para el comando git tag con "git tag -h".

Estamos seguros que con esta información tendrás suficiente para comenzar, pero si te queda alguna duda puedes consultar este artículo de la documentación de Git.