Etiquetas de Git

Tabla de contenidos

¿Qué es un tag?
Tipos de tags
Uso práctico
Gestión de versiones

1. ¿Qué es un tag?

Git tag = etiqueta permanente sobre un commit concreto.

Uso principal: marcar las versiones (v1.0, v2.0, etc.)

Diferencia con las ramas:

Rama = móvil, evoluciona con commits nuevos
Tag = fijo, apunta siempre al mismo commit

Analogía: un tag = una pegatina "Versión 1.0" en una página del cuaderno.

Volver a la tabla de contenidos

2. Tipos de tags

Lightweight tag (simple)

bash

git tag v1.0                # Tag simple

Solo un nombre
Puntero hacia un commit
Rápido de crear

Annotated tag (completo)

bash

git tag -a v1.0 -m "Version 1.0 - First stable release"

Contiene un mensaje
Fecha y autor
Puede firmarse (GPG)
Recomendado para releases oficiales

Volver a la tabla de contenidos

3. Uso práctico

Preparación del proyecto:

bash

mkdir demo-tags && cd demo-tags
git init

echo "print('app v0.1')" > app.py
git add . && git commit -m "Initial version"

echo "print('app v0.2')" > app.py  
git add . && git commit -m "Bug fixes"

echo "print('app v1.0')" > app.py
git add . && git commit -m "First stable version"

Crear tags:

bash

# Tag simple
git tag v1.0

# Tag con mensaje  
git tag -a v1.0-stable -m "Version 1.0 - Production ready"

# Tag en un commit anterior
git log --oneline           # Ver los hashes
git tag v0.2-beta <hash>    # Tag en un commit concreto

Listar tags:

bash

git tag                     # Todos los tags
git tag -l "v1.*"          # Tags que coinciden con el patrón
git show v1.0              # Detalles del tag

Navegar con tags:

bash

git checkout v1.0          # Ir al commit etiquetado
git checkout main          # Volver a main

Push de tags:

bash

git push origin v1.0       # Push de un tag concreto
git push origin --tags     # Push de todos los tags

Volver a la tabla de contenidos

4. Gestión de versiones

Convención Semantic Versioning:

vMAJOR.MINOR.PATCH
- v1.0.0 → First stable release
- v1.0.1 → Bug fix
- v1.1.0 → New feature (backward compatible)  
- v2.0.0 → Breaking changes

Flujo de release típico:

bash

# Desarrollo terminado
git checkout main
git pull origin main

# Tag de release
git tag -a v1.2.0 -m "Release v1.2.0 - Add user authentication"

# Push del código + tags
git push origin main
git push origin v1.2.0

# O push de todo de una vez:
git push origin main --tags

Gestión de los tags:

bash

# Eliminar un tag local
git tag -d v1.0

# Eliminar un tag remoto
git push origin --delete v1.0

# Modificar un tag (recrearlo)
git tag -d v1.0                           # Eliminar en local
git push origin --delete v1.0             # Eliminar en remoto  
git tag -a v1.0 -m "Corrected message"    # Recrear
git push origin v1.0                      # Volver a hacer push

Casos de uso:

1. Release en producción:

bash

git tag -a v2.1.0 -m "Production release v2.1.0"
git push origin v2.1.0
# Deploy version v2.1.0 en production

2. Volver a una versión anterior:

bash

git checkout v2.0.0        # Volver a una versión estable
git checkout -b hotfix-v2.0.0    # Crear una rama hotfix

3. Comparar versiones:

bash

git diff v1.0.0 v2.0.0     # Ver todos los cambios

Los tags = hitos permanentes de tu proyecto. Úsalos en todas las releases.