Marcar lo importante: etiquetas como referencias estables en Git
Llegados a este punto, ya sabes que un proyecto en Git no es solo una sucesión de commits. Has aprendido a crear historia, a corregir errores, a trabajar en paralelo y a colaborar de forma segura. Pero cuando la historia empieza a crecer, aparece una nueva necesidad:
“No todos los momentos del proyecto tienen el mismo valor”.
Hay commits que son simples pasos intermedios y otros que representan algo especial: una versión estable, un punto de entrega, un hito importante. Git ofrece una herramienta específica para señalar esos momentos sin alterar nada más: las etiquetas.
Qué problema resuelven las etiquetas
En un proyecto real, la pregunta no suele ser “¿cuántos commits hay?”, sino:
“¿Cuál es la versión buena?”
“¿Desde qué estado se publicó esto?”
“¿Exactamente qué código corresponde a la versión 1.0?”
Las ramas se mueven. Los commits se acumulan. Una etiqueta, en cambio, no se mueve. Una etiqueta es un nombre fijo que apunta a un commit concreto y dice:
“Este estado del proyecto es importante”.
Pensar las etiquetas como puntos clavados en la historia
Una buena forma de entenderlas es esta analogía:
La historia del proyecto es una carretera.
Los commits son los metros que avanzas.
Las etiquetas son hitos de piedra con un nombre grabado.
Puedes seguir avanzando, pero el hito se queda exactamente donde lo colocaste.
Qué es exactamente una etiqueta en Git
Desde el punto de vista técnico, una etiqueta es una referencia directa a un commit concreto. No crea una nueva versión del código, no duplica archivos y no modifica la historia.
Solo añade un nombre estable a un punto concreto de la línea temporal.
Visualmente, la historia empieza a verse así:
Ese commit marcado como “Versión estable” puede tener una etiqueta como v1.0.0. Aunque el proyecto siga avanzando, esa referencia nunca cambia.
Etiquetas ligeras y etiquetas anotadas
Git permite dos formas de crear etiquetas. El concepto es el mismo, pero el nivel de información cambia.
- Una etiqueta ligera es solo un nombre apuntando a un commit. Es rápida y simple, pero no guarda contexto adicional.
- Una etiqueta anotada, en cambio, guarda información extra: quién la creó, cuándo y con qué mensaje. Es una etiqueta con memoria.
Para marcar versiones de software, la idea importante es esta:
Las versiones importantes deben explicarse, no solo nombrarse.
Por eso, en la práctica profesional, las etiquetas anotadas son la opción correcta.
Crear una etiqueta para una versión estable (ejemplo real)
Imagina un proyecto sencillo. Has llegado a un punto en el que el código funciona bien y quieres marcarlo como versión inicial.
Primero te aseguras de estar en el estado correcto del proyecto. Después creas la etiqueta:
git tag -a v1.0.0 -m "Primera versión estable del proyecto"
Con esto ocurre algo muy concreto: el commit actual queda marcado de forma permanente como v1.0.0. Nada más cambia. El proyecto puede seguir avanzando.
Las etiquetas no se mueven, las versiones evolucionan
Este punto es clave para evitar errores conceptuales. Si más adelante encuentras un fallo y lo corriges, no modificas la etiqueta existente. Creas una nueva.
El flujo mental correcto es este:
Cada etiqueta representa un estado exacto del proyecto en un momento concreto. No se reescriben. No se reutilizan. Esto convierte las etiquetas en contratos: cualquiera que use v1.0.0 sabe exactamente qué código está usando.
Versionado semántico: poner orden a los nombres
Para que las etiquetas tengan sentido compartido, se suele seguir una convención simple llamada versionado semántico.
La estructura es siempre la misma:
MAYOR.MENOR.PARCHE
- El número mayor cambia cuando rompes compatibilidad.
- El número menor cambia cuando añades funcionalidad sin romper nada.
- El número parche cambia cuando corriges errores.
No es una regla técnica de Git. Es un acuerdo humano que convierte las etiquetas en un lenguaje común.
Usar etiquetas para volver a versiones concretas
Una de las ventajas prácticas de las etiquetas es que te permiten volver exactamente a un estado conocido.
Si necesitas inspeccionar cómo estaba el proyecto en la versión v1.0.0, puedes hacerlo directamente:
git checkout v1.0.0
En ese momento, el proyecto se muestra tal como estaba en esa versión. No estás rompiendo nada ni cambiando la historia. Solo estás mirando.
Si necesitas trabajar desde ahí para corregir algo, puedes crear una rama nueva a partir de esa etiqueta. La etiqueta sigue intacta.
Visualizar etiquetas como referencias fijas
Pensar en etiquetas como “mini ramas” es un error. No avanzan, no reciben commits.
Una forma clara de verlo es esta:
La historia avanza.
Las etiquetas señalan.
Qué debe quedarte claro antes de seguir
Las etiquetas no sirven para trabajar en el día a día. Sirven para comunicar estados importantes, para volver a versiones concretas y para dar estabilidad a la historia del proyecto.
- No añaden complejidad al flujo.
- Añaden claridad.