Todos los cursos > Informática ( TI ) > Herramientas de TI ::

Etiquetas y versiones en Git: tags, releases y entrega confiable

Capítulo 7

Tiempo estimado de lectura: 6 minutos

¿Qué es un tag y por qué se usa para versiones?

Un tag en Git es una referencia con nombre que apunta a un commit específico para marcar un hito estable, típicamente una versión publicable como v1.0.0. A diferencia de una rama, un tag no se mueve: queda “anclado” a ese commit, lo que facilita reproducir exactamente el estado del código que se entregó.

Tags vs releases (en GitHub)

Git define tags (en el repositorio). En plataformas como GitHub, un release suele ser una publicación asociada a un tag, con notas de versión y, opcionalmente, artefactos (por ejemplo, un ZIP generado). En la práctica: tag = marcador técnico; release = entrega documentada para usuarios/equipo.

Tipos de tags: ligeros vs anotados

Tag ligero (lightweight)

Es un puntero simple a un commit. Útil para marcadores rápidos o internos.

git tag v1.0.0

Tag anotado (annotated)

Es un objeto completo en Git: incluye mensaje, autor, fecha y puede firmarse (GPG). Recomendado para versiones públicas o entregas formales porque deja más contexto y trazabilidad.

git tag -a v1.0.0 -m "Release v1.0.0"

¿Cuál usar para versionado?

Para releases: tag anotado (mejor auditoría y metadatos).
Para marcadores temporales: tag ligero (rápido, menos formal).

Flujo práctico de versionado: crear tag, verificar, empujar y asociar notas

Este flujo asume que ya estás en el commit correcto (por ejemplo, el commit que pasó pruebas y está listo para entregar).

Continúa en nuestra aplicación.

Escuche el audio con la pantalla apagada.
Obtenga un certificado al finalizar.
¡Más de 5000 cursos para que explores!

O continúa leyendo más abajo...

Descargar la aplicación

Paso 1: confirmar el commit a versionar

Antes de taggear, verifica que estás en el commit esperado.

git status
git log --oneline -n 5

Si trabajas con una rama de entrega (por ejemplo main), asegúrate de estar actualizado con el remoto.

git fetch --all --tags
git pull

Paso 2: crear el tag (recomendado: anotado)

git tag -a v1.0.0 -m "Release v1.0.0"

Si necesitas taggear un commit específico (por hash) sin moverte de rama:

git tag -a v1.0.0 <commit_sha> -m "Release v1.0.0"

Paso 3: verificar el tag

Comprueba que el tag apunta al commit correcto y revisa sus metadatos.

git show v1.0.0

Para ver el commit al que apunta:

git rev-list -n 1 v1.0.0

Paso 4: empujar el tag al remoto

Los tags no se suben automáticamente con git push (a menos que lo indiques).

git push origin v1.0.0

Para empujar todos los tags locales pendientes:

git push origin --tags

Paso 5: asociar notas de versión (release notes) en GitHub

En GitHub, crea un Release basado en el tag:

Ve a Releases → Draft a new release.
Selecciona el tag v1.0.0 (o créalo ahí si aún no existe).
Agrega título y notas: cambios, correcciones, instrucciones de actualización.

Como alternativa automatizable, puedes generar un borrador de notas con commits entre tags (ver sección de comparación).

Listar, buscar y ordenar tags

Listar tags

git tag

Listar con patrón (buscar por prefijo)

git tag -l "v1.*"

Ordenar por versión (útil con SemVer)

git tag -l "v*" --sort=v:refname

Ver tags anotados con su mensaje

git tag -n

Comparar versiones: qué cambió entre dos tags

Ver diferencias de código

git diff v1.0.0..v1.0.1

Ver lista de commits entre versiones

git log --oneline v1.0.0..v1.0.1

Ver archivos cambiados entre versiones

git diff --name-status v1.0.0..v1.0.1

Generar un borrador simple de notas de versión

Una forma práctica es listar commits con un formato consistente:

git log v1.0.0..v1.0.1 --pretty=format:"- %s (%h)"

Esto te da un texto que puedes pegar en el Release de GitHub.

Prácticas recomendadas para equipos

Convención de nombres: SemVer (vMAJOR.MINOR.PATCH)

Una convención común es SemVer:

MAJOR (v2.0.0): cambios incompatibles.
MINOR (v1.1.0): nuevas funcionalidades compatibles.
PATCH (v1.0.1): correcciones compatibles (bugfix).

Recomendación práctica: prefija con v (por ejemplo v1.0.0) para distinguir tags de otros nombres.

¿Cuándo taggear?

Después de pruebas: taggea el commit que pasó CI/tests y revisión.
Después de integrar en la rama de entrega (por ejemplo main), no en una rama personal.
Con notas claras: si es anotado, el mensaje debe resumir la entrega.

Cómo evitar taggear commits incorrectos

Verifica el commit con git show y revisa que incluye lo esperado (archivos y cambios).
Usa un checklist (manual o en CI): pruebas verdes, versión actualizada, changelog listo.
Taggea por SHA si hay riesgo de estar en un commit equivocado: git tag -a vX.Y.Z <sha> -m "...".
Protege la rama en GitHub: evita que se taggee sobre commits no revisados (política de equipo).

Si te equivocaste: eliminar o mover un tag (con cuidado)

En equipos, mover tags publicados puede romper automatizaciones. Si ya se publicó, considera crear un nuevo tag (por ejemplo v1.0.0-hotfix o v1.0.1) en lugar de reescribir. Si aún así necesitas borrar:

# borrar local
git tag -d v1.0.0

# borrar remoto
git push origin :refs/tags/v1.0.0

Para recrearlo apuntando al commit correcto:

git tag -a v1.0.0 <commit_sha_correcto> -m "Release v1.0.0 (fix tag)"
git push origin v1.0.0

Nota: si el remoto ya tenía el tag, puede requerir forzar o borrar primero; coordínalo con el equipo.

Ejemplo con trazabilidad: v1.0.0 y v1.0.1 (cambios mínimos)

Escenario

Supón una app con un endpoint y un archivo CHANGELOG.md. Se entrega v1.0.0 con la funcionalidad base. Luego se detecta un bug menor y se entrega v1.0.1 con una corrección pequeña.

1) Crear v1.0.0 (release inicial)

Tras pasar pruebas, taggeas el commit de entrega:

git tag -a v1.0.0 -m "Release v1.0.0: primera versión estable"
git show v1.0.0
git push origin v1.0.0

Notas de versión sugeridas (para GitHub Release):

Added: endpoint /health
Added: documentación inicial

2) Corregir un bug y crear v1.0.1 (patch)

Se corrige un detalle mínimo (por ejemplo, un código de estado incorrecto o un typo en validación). Luego comparas contra la versión anterior para validar el alcance:

git diff v1.0.0..HEAD
git log --oneline v1.0.0..HEAD

Cuando el commit está listo y probado, creas el tag:

git tag -a v1.0.1 -m "Release v1.0.1: corrección menor"
git show v1.0.1
git push origin v1.0.1

Para trazabilidad, genera el listado de cambios exactos entre versiones y úsalo como base de release notes:

git log v1.0.0..v1.0.1 --pretty=format:"- %s (%h)"

Tabla rápida: qué revisar antes de publicar un tag

Chequeo	Comando/Acción	Objetivo
Estás en el commit correcto	`git log -n 1`	Evitar tag en commit equivocado
El tag apunta bien	`git show vX.Y.Z`	Confirmar contenido y metadatos
Subiste el tag	`git push origin vX.Y.Z`	Que el equipo/CI lo vea
Notas de versión	GitHub Release + `git log A..B`	Entrega documentada y auditable

Ahora responde el ejercicio sobre el contenido:

¿Qué diferencia práctica describe mejor la relación entre un tag en Git y un release en GitHub al publicar una versión?

¡Tienes razón! Felicitaciones, ahora pasa a la página siguiente.

¡Tú error! Inténtalo de nuevo.

Un tag apunta a un commit fijo para identificar una versión exacta. Un release es la entrega asociada a ese tag, normalmente con notas de versión y, si se desea, archivos adjuntos.