hand Inicio

Cómo trabajar con GIT TAG

Los tags en git son etiquetas para identificar mejor aquellos commits de git que merezcan la pena, lo que nos servirá para poder referenciarlo con comodidad

git

git nos permite tener un control de la evolución de nuestro desarrollo (tienes una entrada de la guía simple de git)

Esto lo hacemos con:

  1. stage via git add * o git add tu_archivo.js
  2. commit via git commit -m "he añadido esto"
  3. push via git push origin master

El stage nos sirve para agrupar archivos que hemos cambiado, y luego poder hacer un commit de ellos con un mensaje adecuado, así si tenemos 20 archivos cambiados podemos separar los stage y commits en varios grupos

En cualquier momento podemos hacer el push para sincronizar los contenidos entre el local y el remoto (por ejemplo en github), y es en ese momento donde podemos añadir un tag o label o etiqueta a nuestro commit para dotarle de (más) significado

git tag

Con el comando git tag (equivalente a git tag -l o git tag --list) veremos los tags que tenemos existentes

Si queremos crearlos, lo hacemos con git tag -a miEtiqueta -m "el mensaje que quedamos que acompañe a la etiqueta

bash
$ git tag -a v0.1 -m "texto que queremos poner, como por ejemplo version 0.1"
$ git tag

v0.1

Ese tag que acabamos de crear estará vinculado al git commit que hayamos hecho anteriormente

git show

Una vez creado el tag después del commit correspondiente, podremos explorar cualquier tag con git show donde no sólo veremos las etiquetas sino también los cambios a nivel de código que se han producido

bash
$ git tag -a v0.1 -m "texto que queremos poner, como por ejemplo version 0.1"
$ git show v0.1

tag kuworking@0.1
Tagger: kuworking
Date: Tue Jun 20 08:43:10 2019 +0200

kuworking@0.1

commit 280a654f0e63fec63457ffdee95c4779e917adre (tag: site@0.1, tag: kuworking@0.1)
Author: kuworking
Date: Tue Jun 20 08:43:10 2019 +0200

Publish

- kuworking@0.1
- site@0.1

diff --git a/packages/kuworking/package.json b/packages/kuworking/package.json
index 6ede0d8..19a93f2 100644
--- a/packages/kuworking/package.json
+++ b/packages/kuworking/package.json
@@ -1,6 +1,6 @@
{
"name": "kuworking",
- "version": "0.01",
+ "version": "0.1",
"private": true,
"description": "kuworking.com",
"author": "kuworking",
...

git tag (ligero)

Si queremos almacenar la etiqueta con menos información, podemos hacer un tag lightweight

bash
$ git tag v0.1
$ git show v0.1

La diferencia es que el vínculo entre el tag y el commit no será tan permanente, pero igualmente podremos apuntar a ese tag si nos interesa

Borrar un tag

Borrar un tag por un error o por una rutina que se ha interrumpido inesperadamente es algo que podemos hacer de forma sencilla con

bash
$ git tag -d v0.1

Deleted tag 'v0.1' (was 9165190)

Esto sólo borra el tag a nivel local, por lo que si antes habíamos sincronizado con push también necesitaremos borrar el tag en remote

bash
$ git push origin --delete v0.1

Y para ver los tags en remote, haríamos

bash
$ git ls-remote --tags origin
e8a0cc653954551c4838966d1c1178110892a802 refs/tags/v0.0.2
81101b87b2e02dcfefa326cbe35ae1e6904b2bca refs/tags/v0.0.3
4287f60d08a9ce19e27fc1f67e546f6b1300ad1b refs/tags/v0.0.7

Cuando vale la pena hacer el git tag?

El gran uso de los tags es cambiar el identificador de un commit con un texto tipo 0d52aaab4479697da7686c15f77a3d64d9165190, por un texto tipo draft01, mucho más amigable

Y para qué queremos commits que tengan nombres "humanos"?

Porque podemos movernos a ese commit específico, y a partir de ahí hacer cambios en ese código y crear una rama paralela, o simplemente explorar el código y listos

Otra aplicación de tener un tag específico es que podremos instalar esa particular versión de forma muy fácil en package.json

Lo que nos ahorramos aquí es el tener que poner ese hash tan poco amigable de antes (y tan rebuscado de encontrar, por otro lado)

json
"myPublicPackage": "git+https://github.com/myUser/myPublicPackage.git#v0.0.14",
"myPrivatePackage": "git+https://miTokenParaAcceder:x-oauth-basic@github.com/myUser/myPrivatePackage.git#v0.0.14",

Esto es muy útil cuando estemos utilizando el git de forma directa (aquí en github), en lugar de publicar los paquetes via npm

En resumen, con git tenemos un control de nuestro desarrollo, y con git tag podemos dotar de significado a los puntos de control del desarrollo (los commits), es decir, facilitar la identificación de distintos commits para su futura referencia

Lo suyo no es poner etiquetas a todos los commits, sólo a aquellos que representen estados que merezcan la pena ser remarcados

draw of me

Hola, tienes en mente desarrollar una web?

Si quieres, te ayudo

Escríbeme