Git Tag y Versionado Semántico (SemVer): Cómo Publicar Releases Oficiales
Comprende la diferencia entre tags ligeros y anotados, y domina el estándar MAJOR.MINOR.PATCH para lanzar versiones profesionales en GitHub.
A medida que un proyecto evoluciona, acumula cientos o miles de commits continuos (`feat: arreglar botón`, `fix: error de typo`). Sin embargo, los clientes, los usuarios finales y los gestores de paquetes (como NPM o PyPI) no descargan commits individuales con hashes hexadecimales incomprensibles como `7f3b9c2`: ellos descargan versiones oficiales como la **v1.0.0** o la **v2.4.1**. Un **Git Tag** (etiqueta) es una marca permanente e inmutable que se fija a un commit específico del historial para señalar un hito importante (un lanzamiento de release). A diferencia de una rama (branch) —que se mueve hacia adelante con cada nuevo commit—, un tag **permanece congelado para siempre** en ese punto exacto del tiempo. Para que los números de versión tengan sentido lógico en todo el planeta, la industria sigue el estándar **SemVer (Semantic Versioning)**, compuesto por tres números: **MAJOR.MINOR.PATCH** (ejemplo: `v2.1.4`).
- ✓PATCH (Corrección de Errores - Bugfixes): Incrementa cuando solucionas fallos internos sin alterar la compatibilidad ni agregar funciones (ej. `v1.0.0` -> `v1.0.1`). Es 100% seguro de actualizar.
- ✓MINOR (Nueva Funcionalidad Compatible): Incrementa cuando agregas nuevas características a tu software pero mantienes la compatibilidad con el código anterior (ej. `v1.0.1` -> `v1.1.0`).
- ✓MAJOR (Breaking Changes - Ruptura de Compatibilidad): Incrementa cuando modificas la arquitectura o eliminas funciones de forma que el código de los usuarios dejará de funcionar si no actualizan sus llamadas (ej. `v1.1.0` -> `v2.0.0`).
- •Permite a gestores de paquetes como NPM o Composer actualizar dependencias automáticamente sin romper tu servidor.
- •Facilita a los equipos de soporte saber exactamente qué versión de código tiene instalada un cliente con problemas.
- •Dispara pipelines automatizados de CI/CD para compilar binarios y desplegar a producción automáticamente cada vez que se detecta un nuevo tag.
Imagina un libro de texto universitario de matemáticas: - Si la editorial reimprime el libro para corregir tres faltas de ortografía en la página 40, lanza la **Edición 1.0.1 (PATCH)**. Los ejercicios de los alumnos no cambian en nada. - Si la editorial agrega un capítulo extra de álgebra avanzada al final del libro, publica la **Edición 1.1.0 (MINOR)**. Todo lo que los alumnos ya habían estudiado sigue estando en las mismas páginas, pero ahora tienen material nuevo disponible. - Si la editorial decide reordenar todo el temario, cambiar las fórmulas y eliminar temas obsoletos, publica la **Segunda Edición 2.0.0 (MAJOR)**. Un alumno con el libro viejo ya no podrá seguir la clase del profesor si este enseña con la edición 2.0.0.
Explicación Paso a Paso del Tema
Tags Ligeros (Lightweight) vs Tags Anotados (Annotated)
En Git existen dos clases de etiquetas: - **Tag Ligero**: Es solo un puntero simple sin autor ni mensaje (como un post-it rápido). - **Tag Anotado (Recomendado)**: Se almacena como un objeto completo en la base de datos de Git con el nombre del autor, correo, fecha, mensaje descriptivo e incluso firma criptográfica GPG.
Usa siempre la bandera `-a` para crear tags anotados oficiales de producción.
git tag -a v1.0.0 -m "Release inicial de producción: autenticación y pasarela de pagos"
| Parámetro / Flag | Tipo / Rol | Significado y Uso |
|---|---|---|
| -a v1.0.0 | Flag y Nombre | Crea un tag anotado con el identificador de versión SemVer. |
| -m "..." | Mensaje | Describe los cambios y novedades incluidos en el lanzamiento. |
Puedes inspeccionar los metadatos completos de un tag anotado ejecutando `git show v1.0.0`.
Subir (Push) los Tags a GitHub
Hacer `git push` normal sube tus ramas de código pero **no sube los tags**. Debes enviar los tags explícitamente al repositorio remoto.
Puedes subir un tag individual o todos los tags pendientes con `--tags`.
# Subir un tag específico: git push origin v1.0.0 # O subir todos los tags locales pendientes: git push origin --tags
| Parámetro / Flag | Tipo / Rol | Significado y Uso |
|---|---|---|
| --tags | Flag | Envía todas las referencias de etiquetas que aún no existen en el servidor remoto. |
Olvidar hacer `git push origin --tags`: crearás el tag en tu máquina local pero tus compañeros y los pipelines de GitHub no verán el release.
Convertir un Git Tag en una Release Oficial en GitHub
Cuando subes un tag a GitHub, aparece automáticamente en la pestaña 'Tags'. Desde allí puedes hacer clic en 'Create Release from tag'.
GitHub generará automáticamente un archivo comprimido `.zip` y `.tar.gz` del código congelado en ese tag y te permitirá adjuntar notas de lanzamiento (Changelog) y binarios compilados.
Usa herramientas como `release-it` o `semantic-release` para automatizar completamente la creación de tags, changelogs y releases en tu pipeline de CI/CD.
Casos Prácticos Reales en Producción
Situaciones de ingeniería reales sin mención de presupuestos ficticios.
1El Hotfix de Emergencia sobre una Versión Antigua en Producción
Una empresa tenía clientes operando en la versión `v2.4.0` en producción, mientras que la rama `main` de desarrollo ya estaba en la versión preliminar `v3.0.0-beta`. Se descubrió un fallo crítico de seguridad que afectaba a la `v2.4.0`.
En lugar de obligar a los clientes a actualizar a la versión 3 beta inestable, crearon una rama a partir del tag: `git checkout -b hotfix-v2 v2.4.0`, aplicaron la corrección, y crearon el tag `v2.4.1`.
Fichas Nemotécnicas de Conceptos Clave
Glosario rápido para recordar los términos fundamentales de la lección.
Referencia inmutable que marca un commit específico del historial para identificar hitos de versiones o releases.
Estándar formal de tres componentes (MAJOR.MINOR.PATCH) que comunica el nivel de impacto y compatibilidad de una actualización.
Modificación en el software que rompe la compatibilidad hacia atrás, obligando a incrementar la versión MAJOR.
Git Tag y Versionado Semántico (SemVer): Cómo Publicar Releases Oficiales
Selecciona una opción para autoevaluarte al instante. La respuesta se califica de inmediato.
Bajo las reglas de Versionado Semántico (SemVer), si lanzas una actualización que corrige dos fallos de seguridad sin cambiar las funciones existentes, ¿qué número debes incrementar?
¿Qué diferencia principal existe entre una rama (branch) y una etiqueta (tag) en Git?
¿Por qué se recomienda utilizar tags anotados ('git tag -a') en lugar de tags ligeros para versiones de producción?
Preguntas Frecuentes (FAQ)
¿Cómo puedo etiquetar un commit antiguo del pasado si olvidé hacerlo en su momento?
Simplemente pasa el hash del commit al final del comando: `git tag -a v1.2.0 9fceb02 -m "Release retroactivo v1.2.0"`.
¿Cómo se elimina un tag tanto localmente como en GitHub si me equivoqué de nombre?
Bórralo localmente con `git tag -d v1.0.0` y luego bórralo del servidor remoto con `git push origin --delete v1.0.0`.