- 1. Git Config
- 2. Iniciando o Clonando un repositorio
- 3. Comandos Básicos
- 4. El archivo .gitignore
- 5. Trabajando con ramas
- 6. Deshaciendo y modificando commits
- 7. Commits Semánticos
- 8. Tags
- 9. Comandos Avanzados
- 10. Gita Aliases
- 11. Git Flow
En este octavo artículo sobre la guía para aprender Git de manera sencilla y desde cero, vamos a ver los Tags de Git. Como muchos VCS, Git tiene la posibilidad de etiquetar puntos específicos del historial como importantes. Esta funcionalidad se usa típicamente para marcar versiones de lanzamiento (v1.0.0, por ejemplo).
Semantic Version
El versionado semántico, semantic version (SemVer) en inglés, es una convención para marcar las diferentes versiones que se lanzan de un software en desarrollo.
Un número normal de versión tiene la forma X.Y.Z, donde X, Y, y Z son números enteros no negativos. X es la versión major, Y es la versión minor, y Z es la versión patch. Cada elemento debe incrementarse numéricamente en incrementos de 1. Por ejemplo: 1.9.0 -> 1.10.0 -> 1.11.0.
El propio WordPress lo utiliza para cada versión que saca, aunque suele omitir el último número si la release corresponde a una major o una minor inicial. Por ejemplo la versión 5 es la 5.0 (en lugar de la 5.0.0), la 5.5 no lleva el último dígito (debería ser la 5.5.0). Sin embargo, cuando hay actualizaciones de seguridad y/o vulnerabilidades, este número si está presente, por ejemplo WordPress 5.5.3
Una vez que un paquete versionado ha sido liberado (release), los contenidos de esa versión no deben ser modificados. Cualquier modificación debe ser liberada como una nueva versión.
- La versión major 0 debe utilizarse para el desarrollo inicial de un software. Será 1 cuando se ponga en producción. Representa grandes evolutivos, o modificaciones que dejan obsoleta la versión anterior o parte de ella. Durante la vida de una versión major, pueden incluirse cambios de nivel minor y/o patch. Las versiones patch y minor deben ser reseteadas a 0 cuando se incrementa la versión major.
- La versión minor debe ser incrementada si se introduce nueva funcionalidad compatible con la versión major. Suelen ser evolutivos y/o mejoras, pero que no representen una ruptura con la versión anterior. Puede incluir cambios de nivel patch. La versión patch debe ser reseteada a 0 cuando la versión minor es incrementada.
- La versión patch debe incrementarse cuando se detectan y corrigen fallos y/o vulnerabilidades en la versión actual de nuestro software. No se agrega nueva funcionalidad, simplemente corrección de errores.
Listar Tags
Utilizaremos el comando git tag
para listar las etiquetas que se han creado en un proyecto. Este comando lista las etiquetas en orden alfabético. Devolverá algo parecido a esto:
v0.1.0
v0.2.0
v1.0.0
v1.0.1
También puedes buscar etiquetas con un patrón particular. El repositorio del código fuente de Git, por ejemplo, contiene más de 500 etiquetas. Si sólo te interesa ver la serie 1.8.5, puedes ejecutar:
git tag -l 'v1.8*'
v1.8.0
v1.8.1
v1.8.2
v1.8.3
Crear Etiquetas
Git utiliza dos tipos principales de etiquetas: ligeras y anotadas. Difieren en la cantidad de metadatos adjuntos que almacenan. Las etiquetas anotadas almacenan metadatos adicionales: tienen un checksum, el nombre de la persona que etiqueta, su correo electrónico, la fecha, descripción… Las etiquetas ligeras son básicamente «marcadores» de una confirmación, son solo un nombre y un puntero a una confirmación.
Para crear etiquetas anotadas utilizaremos el comando git add
con el flag -a
. Con el flag -m
podemos añadir el mensaje de la etiqueta, este será un mensaje corto pero descriptivo. Si no añades esta opción te abrirá un editor (el editor por defecto) para añadir un mensaje para ese tag con mucho más detalle.
git tag -a v1.4.0 -m 'add: version v1.4.0'
Etiquetado tardío
También puedes etiquetar commits mucho tiempo después de haberlos hecho. Simplemente localiza el hash del commit sobre el que vas a etiquetar una versión y pásalo como argumento al comando git tag
:
git tag -a v1.2.0 [commit_hash]
Subir etiquetas al repositorio
Por defecto, el comando git push
no transfiere etiquetas al repositorio remoto. Debes indicarlo explícitamente una vez las hayas creado:
git push origin [tagname]
Si tienes varias etiquetas por subir al repositorio de golpe, puedes hacerlo con el comando:
git push origin --tags
Eliminar tags
Debemos tener en cuenta si lo que queremos borrar es una tag que aún no hemos trackeado al repositorio remoto o si:
# Tag local
git tag -d [tag_name]
# Tag en remoto
git push origin --delete [tag_name]