Una tag es una referencia estática que sirve para marcar un punto específico e inmutable en el historial de tu repositorio.
Hemos aprendido que las branches son punteros móviles. Cuando haces un commit, la rama avanza. Son etiqueta vivas y dinámicas.
Pero a veces necesitamos hacer justo lo contrario: queremos marcar un punto fijo e inmutable en la historia. Queremos decir: “Este commit exacto es la Versión 1.0 que hemos entregado al cliente”.
Para esto, Git nos ofrece las Etiquetas o git tag. Hoy vamos a ver cómo usar estas “chinchetas” para organizar nuestros release y el cómo usarlas para gestionar el versionado de nuestro proyecto 👇.
¿Qué es un Tag?
Técnicamente, un tag es muy parecido a una rama: es un puntero a un commit específico. La gran diferencia es que el tag NO se mueve.
Si haces un commit nuevo, la rama avanzará, pero el tag se quedará para siempre señalando a ese commit antiguo. Es la forma perfecta de marcar hitos: v1.0, v2.1-beta, publicación-2023.
Aunque puedes llamar a tus tags como quieras, el estándar de la industria es usar Versionado Semántico.
Tipos de etiquetas
Git tiene dos tipos de etiquetas. Elegir una u otra depende de la importancia de lo que estés marcando.
Son simplemente un puntero a un commit (como una rama que no cambia). No guardan autor, ni fecha, ni mensaje propio. Son como un “marcapáginas” rápido.
Cómo se crean:
git tag v1.0-wip
¿Cuándo usarlas? Para uso personal o temporal. “Quiero marcar este punto para probar algo luego”.
Esta es la opción adecuada para lanzamientos de software. Las etiquetas anotadas se guardan en la base de datos de Git como objetos completos.
Contienen:
- El nombre del tag.
- El nombre y correo de la persona que creó el tag.
- La fecha del etiquetado.
- Un mensaje de etiquetado (similar al mensaje del commit).
Cómo se crean: Usamos la opción -a (annotated) y -m (mensaje):
git tag -a v1.0.0 -m "Versión 1.0.0 - Lanzamiento oficial"
¿Cuándo usarlas? Siempre que vayas a liberar una versión pública del software.
Lo recomendable es usar Etiquetas anotadas por defecto. La información extra (quién hizo la release y cuándo) que es importante para identificarlos en el futuro.
Trabajando con Tags
Si llevas años trabajando, tendrás muchas versiones. Para verlas:
git tag
Si buscas una serie específica (por ejemplo, todas las 1.x):
git tag -l "v1.*"
A veces se te olvida crear el tag el día del lanzamiento. Te das cuenta tres días después. No hay problema.
Puedes etiquetar un commit antiguo especificando su Hash al final del comando:
git tag -a v0.9.0 a1b2c3d -m "Versión Beta olvidada"
Para ver los detalles de una etiqueta anotada y el commit al que apunta:
git show v1.0.0
Subir etiquetas al servidor
Por defecto, el comando git push no transfiere las etiquetas a los servidores remotos. Tienes que subirlas explícitamente.
Para subir una etiqueta concreta:
git push origin v1.0.0
Para subir TODAS tus etiquetas de golpe:
git push origin --tags
Usa --tags con cuidado si tienes muchas etiquetas “basura” en local que no quieres compartir con el equipo.
Borrar etiquetas
Si te has equivocado (por ejemplo, has puesto v1.0.1 en un commit que tenía un bug), puedes borrar la etiqueta.
Borrar en local:
git tag -d v1.0.1
Borrar en remoto (GitHub/GitLab): Igual que borramos ramas remotas, necesitamos un comando especial de push:
git push origin --delete v1.0.1
