guides

Una etiqueta (tag) de Git es una referencia con nombre que apunta a un commit concreto de un repositorio. Mientras que un commit se identifica por un hash largo y difícil de recordar, una etiqueta da a ese punto exacto de la historia un nombre corto y legible. Las etiquetas se usan sobre todo para marcar puntos de release, de modo que un nombre como v1.0.0 se refiere al estado preciso del código que se publicó como esa versión.

La diferencia clave entre una etiqueta y una rama es que una etiqueta no se mueve. Una rama es un puntero que avanza cada vez que le añades un nuevo commit, siguiendo siempre el trabajo más reciente. Una etiqueta es fija: una vez que la asocias a un commit, sigue apuntando a ese mismo commit aunque el desarrollo continúe más allá. Esto es exactamente lo que quieres para una release, porque el significado de v1.0.0 nunca debería cambiar después de publicarse.

Etiquetas ligeras frente a anotadas

Git admite dos tipos de etiquetas: etiquetas ligeras y etiquetas anotadas. Una etiqueta ligera es poco más que un nombre que apunta directamente a un commit, sin información adicional almacenada junto a ella. Es rápida de crear y funciona bien como marcador personal, pero no guarda ningún registro de quién la creó ni por qué.

Una etiqueta anotada se almacena como un objeto completo en la base de datos de Git. Registra el nombre de la persona que creó la etiqueta, la fecha en que se hizo y un mensaje de etiquetado, de forma muy parecida a como un commit registra su autor y su mensaje. Las etiquetas anotadas también pueden firmarse con GPG, lo que permite a otros verificar que una etiqueta de release proviene realmente de ti. Para las releases públicas, las etiquetas anotadas suelen ser la opción recomendada por estos metadatos adicionales y la posibilidad de firmarlas.

Crear y enviar etiquetas

Crear etiquetas es sencillo. Ejecutar git tag con un nombre y sin más opciones crea una etiqueta ligera en el commit actual. Añadir la opción -a, como en git tag -a v1.0.0 -m "Release 1.0.0", crea una etiqueta anotada con un mensaje. También puedes etiquetar un commit anterior pasando su hash al final del comando, lo que resulta útil cuando te das cuenta después de que un commit concreto era el verdadero punto de release.

• Una etiqueta nombra un commit concreto; a diferencia de una rama, no se mueve una vez fijada.
• Etiqueta ligera: solo un nombre que apunta a un commit, sin metadatos adicionales.
• Etiqueta anotada: un objeto completo que almacena autor, fecha y mensaje, y puede firmarse con GPG.
• Se crea con git tag v1.0.0 (ligera) o git tag -a v1.0.0 -m "..." (anotada).
• Las etiquetas no se envían por defecto: mándalas con git push origin <tag> o git push --tags.
• Las etiquetas marcan releases, a menudo como SemVer vX.Y.Z, y suelen activar CI/CD y páginas de release.

Un detalle que sorprende a los principiantes es que las etiquetas no se comparten automáticamente. Cuando ejecutas git push, tus ramas se actualizan en el remoto, pero tus etiquetas permanecen locales a menos que las envíes explícitamente. Envías una sola etiqueta con git push origin seguido del nombre de la etiqueta, o mandas todas tus etiquetas de una vez con git push --tags. Olvidar este paso es una razón habitual de que una etiqueta de release aparezca en la máquina de un desarrollador pero falte en el repositorio compartido.

Etiquetas, versionado y automatización de releases

Las etiquetas encajan de forma natural en un esquema de versiones. Muchos proyectos siguen el versionado semántico, donde una versión tiene la forma MAYOR.MENOR.PARCHE, y cada release se captura como una etiqueta correspondiente como v2.4.1. Como la etiqueta es inmutable, cualquiera puede más tarde extraer esa etiqueta exacta y reconstruir el código tal como estaba para esa versión, lo que constituye la base de las releases reproducibles.

Las etiquetas también impulsan buena parte de la automatización. Las canalizaciones de integración y despliegue continuos suelen configurarse para activarse cuando se envía una nueva etiqueta, de modo que etiquetar un commit como v1.2.0 construye, prueba y publica automáticamente esa versión. Las plataformas que alojan repositorios a menudo convierten las etiquetas en páginas de release, adjuntando notas y artefactos descargables a cada versión etiquetada. Así, un pequeño puntero inmutable se convierte en el ancla de todo un proceso de release.

Trabajar con etiquetas de forma segura

Como una etiqueta es solo una referencia, es barata y segura de manejar. Listar etiquetas, inspeccionar lo que dice una etiqueta anotada o extraer el código en una etiqueta concreta son operaciones de solo lectura que no perturban tu trabajo en curso. Eliminar una etiqueta localmente también es sencillo, aunque eliminar una que ya se ha enviado y que otros usan debe hacerse con cuidado, porque personas y canalizaciones pueden depender ya de ella.

En resumen

En resumen, una etiqueta de Git es una marca estable sobre un momento de la historia de tu proyecto. Las etiquetas ligeras son referencias personales rápidas, mientras que las etiquetas anotadas llevan autoría, un mensaje y firmas opcionales que las hacen adecuadas para releases públicas. Combinadas con un esquema de versiones y enviadas al remoto compartido, las etiquetas convierten un hash de commit imposible de memorizar en una referencia duradera y verificable para una versión concreta de tu software.