handHOME

Cómo trabajar con GIT TAG

Diciembre del 2021

git

git nos permite tener un control de la evolución de nuestro desarrollo

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 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

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

v0.1

Y este 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

$ 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",
   "description": "kuworking.com",
   "author": "kuworking",
   ...

git tag (ligero)

Si queremos almacenar la etiqueta con menos información, en lugar del tag anterior (annotated) también podemos hacer un tag lightweight (sin anotación, en git te explican estos dos tipos de tags)

$ 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

$ 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

$ git push origin --delete v0.1

Para ver los tags en remote, haríamos

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

Para qué hacer un git tag?

Más allá de darle una frase entendible al commit , también podemos distribuir la instalación de esa versión concreta via github apuntando al tag en particular (esto es si no queremos utilizar npm):

"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",
El texto está en blanco!
Enviado!