Cuando un proyecto empieza a crecer, no basta con guardar cambios en commits y ramas. Llega un punto en el que necesitas señalar hitos claros: una versión estable, un lanzamiento público o una release candidata. Ahí es donde git tag se vuelve imprescindible.
Etiquetar versiones en Git te permite poner nombre a un estado concreto del repositorio. Esa referencia es especialmente útil para equipos de desarrollo, despliegues, automatización de releases y tareas de mantenimiento. Si ya dominas conceptos como git log, verás que los tags complementan muy bien el historial, porque convierten un commit específico en un punto fácil de recordar.
En este artículo aprenderás qué son los tags, cuándo conviene utilizarlos, cómo crearlos y cómo gestionarlos correctamente en un flujo de trabajo real.
Qué es un tag en Git
Un tag en Git es una etiqueta que apunta a un commit concreto. A diferencia de una rama, un tag no avanza con nuevos commits: permanece fijo en el tiempo. Esa estabilidad lo convierte en una herramienta ideal para marcar versiones.
Piensa en él como una señal permanente en el mapa del proyecto. Mientras una rama sigue el desarrollo activo, el tag sirve para decir: “aquí estaba la versión 1.0.0”, “aquí salió la 2.3.1” o “este commit es la release candidata final”.
Tags ligeros y tags anotados
Git distingue principalmente entre tags ligeros y tags anotados. El primero es básicamente un puntero simple a un commit. El segundo incluye información adicional como autor, fecha, mensaje y, si se desea, firma criptográfica.
Para proyectos profesionales, lo normal es usar tags anotados, porque aportan trazabilidad y contexto. Los tags ligeros pueden servir en pruebas rápidas o usos puntuales, pero suelen quedarse cortos para una estrategia de versionado seria.
Cuándo usar git tag para versionar
Los tags encajan muy bien en escenarios donde necesitas identificar estados estables del software. Por ejemplo: versiones preparadas para producción, entregas a cliente, versiones internas para QA o snapshots previos a una migración importante.
También resultan muy útiles cuando trabajas con integración continua o pipelines de despliegue. Un tag puede lanzar un build determinista, generar artefactos y publicar una release con nombre claro. Si además usas ramas correctamente, como explicamos en qué son las ramas en Git y cómo funcionan, tendrás una división limpia entre desarrollo, mantenimiento y publicación.
Cómo crear una etiqueta de versión
Crear un tag es sencillo. La diferencia real está en elegir el tipo adecuado y en mantener una convención consistente. A continuación, verás ejemplos habituales para marcar una versión con Git.
# Crear un tag anotado para una versión estable
git tag -a v1.0.0 -m "Primera versión estable"
# Crear un tag ligero
git tag v1.0.1
# Crear un tag anotado sobre un commit concreto
git tag -a v1.1.0 4f3c2ab -m "Versión 1.1.0 con mejoras de rendimiento"
La opción -a crea un tag anotado, mientras que -m añade el mensaje descriptivo. Si no indicas un commit, Git etiquetará el commit actual de tu rama. Si te interesa repasar cómo llegar a ese punto exacto desde el trabajo diario, puede ayudarte nuestro artículo sobre cómo crear un commit correctamente con git commit.
Cómo ver las etiquetas existentes
Una vez que el proyecto empieza a acumular versiones, necesitas consultar los tags disponibles. Git ofrece varias formas de hacerlo según el nivel de detalle que busques.
# Listar todas las etiquetas
git tag
# Filtrar etiquetas por patrón
git tag -l "v1.*"
# Ver información completa de una etiqueta anotada
git show v1.0.0
El comando git show es especialmente útil para comprobar el mensaje, el commit asociado y el contenido del tag. Esto ayuda mucho cuando quieres validar qué versión concreta corresponde a una incidencia o a una entrega histórica.
Cómo etiquetar un commit pasado
En la práctica, no siempre vas a crear la etiqueta justo en el momento en que se produce el lanzamiento. A veces descubres más tarde que un commit anterior debería haberse marcado como versión oficial. Git permite hacerlo sin problema.
# Etiquetar un commit antiguo usando su hash
git tag -a v2.0.0 9ad7f12 -m "Versión 2.0.0"
# Verificar que la etiqueta apunta al commit correcto
git show v2.0.0
Esta flexibilidad es muy valiosa cuando trabajas con hotfixes, auditorías o correcciones sobre versiones ya publicadas. Eso sí, conviene evitar que un tag cambie de significado con el tiempo; la etiqueta debe permanecer asociada a un único estado inmutable del proyecto.
Cómo publicar tags en un repositorio remoto
Crear el tag en local no basta si el equipo necesita verlo en GitHub, GitLab u otra plataforma remota. Igual que ocurre con los commits o ramas, debes enviarlo explícitamente al remoto.
# Subir un tag concreto al remoto
git push origin v1.0.0
# Subir todas las etiquetas locales
git push origin --tags
La opción de subir un tag concreto suele ser la más controlada. En cambio, –tags publica todas las etiquetas locales pendientes, algo útil en repositorios pequeños pero potencialmente delicado en entornos grandes. Si todavía no tienes clara la relación entre tu copia local y el servidor remoto, te conviene revisar cómo gestionar repositorios remotos con git remote y cómo subir cambios al repositorio con git push.
Cómo eliminar o mover una etiqueta
Aunque los tags deberían tratarse como referencias estables, a veces hay errores. Puede suceder que el nombre sea incorrecto, que se haya etiquetado el commit equivocado o que un lanzamiento se haya adelantado por accidente.
# Eliminar un tag local
git tag -d v1.0.0
# Eliminar un tag remoto
git push origin --delete v1.0.0
Si necesitas corregir una etiqueta, lo recomendable es borrar la incorrecta y crear una nueva, en lugar de reutilizar silenciosamente el mismo nombre. Esa disciplina evita confusiones en automatizaciones, documentación y despliegues. En Git, la claridad operativa importa tanto como la técnica.
Convenciones de nomenclatura para versiones
Un buen sistema de versionado es tan importante como el propio comando. La forma más extendida es usar SemVer o versionado semántico, con patrones tipo vMAJOR.MINOR.PATCH, por ejemplo v2.4.1.
Esta convención facilita entender si un cambio introduce ruptura, añade funcionalidad o corrige errores. También hace más simple automatizar releases y mensajes de despliegue. Lo importante es que el equipo adopte una regla única y la siga de forma consistente.
Tags y flujos de trabajo de release
En un flujo de trabajo profesional, los tags suelen aparecer al final de una cadena: desarrollo en ramas, validación, merge, pruebas adicionales y, finalmente, publicación de la versión. El tag marca el momento exacto en el que el software queda congelado como release.
Por eso, etiquetar versiones con git tag no es un gesto aislado, sino una pieza dentro de una estrategia más amplia de entrega. Si quieres seguir afinando tu proceso, también es útil dominar herramientas como git merge, git diff y cómo deshacer cambios en Git sin perder tu trabajo para llegar a la release con mayor control.
En entornos modernos, los tags también suelen integrarse con pipelines, generación de changelogs y publicación automática de paquetes. La tendencia general es mover cada vez más tareas repetitivas hacia automatización, pero el principio básico sigue siendo el mismo: la etiqueta debe señalar una versión confiable y reproducible.
Errores comunes al usar git tag
Uno de los fallos más frecuentes es confundir un tag con una rama. El tag no está pensado para seguir el desarrollo, sino para congelarlo. Otro error típico es crear tags sin mensaje o sin convención de nombres, lo que complica la lectura del historial usando git log y la trazabilidad general.
También conviene evitar etiquetar commits intermedios que todavía cambian por encima, salvo que el equipo entienda muy bien el propósito. Un tag debe representar una versión con sentido práctico para desarrollo, QA, producto o cliente.
Conclusión
Aprender a etiquetar versiones con git tag te ayuda a ordenar lanzamientos, mejorar la trazabilidad y hacer que Git sea mucho más útil en equipos reales. Con unos pocos comandos puedes marcar versiones estables, publicar releases y recuperar puntos concretos del proyecto con facilidad.
Si ya trabajas cómodamente con commits, ramas y remoto, el siguiente paso natural es incorporar tags a tu flujo de desarrollo. Te dará control, claridad y una base sólida para versionar software de forma profesional.
Fuentes y lecturas recomendadas
Documentación oficial de git tag
GitHub Docs: releases y etiquetas
Deja una respuesta