hand Inicio

SERVICIOS

Salir

nochedía

DESARROLLO WEB con
GATSBY y WORDPRESS

emoji Cursos [24]
emoji Themes Gatsby [5]
emoji Themes WordPress [2]
emoji Blog [83]
emoji Herramientas [11]

Cómo trabajar con GIT TAG

600 palabras
2 minutos
June 17, 2019
bloggit

Te enseño qué son y cómo utilizar los tags en git

  1. Prólogo
  2. Git tag
  3. Git show
  4. Cuando hacer el git tag?
  5. Borrar un tag
  6. Utilizando tags para package.json
  7. Resumen

Prólogo

En esta entrada voy a hablar del git tagging, esto es utilizar etiquetas o labels para identificar mejor cada release que hacemos con git

Por si quieres refrescar qué es git, puedes consultar la pequeña introducción que hice en la guía simple de git

A modo recordatorio y en pocas frases, git nos permite tener un control de la evolución de nuestro desarrollo con las figuras de

  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 y el commit pueden parecer redundantes, pero la única manera de hacer commits de diferentes grupos de archivos es seleccionando esos archivos con stage antes, de otro modo sólo podríamos hacer un gran commit con todas las modificaciones existentes (puedes leerlo en esta respuesta de stackoverflow)

Una vez decidimos el commit y seguimos con el push para sincronizar los contenidos (por ejemplo en github), es entonces cuando podemos añadir un tag o label o etiqueta a nuestro commit para dotarle de significado

Git tag

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

Antes, para 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 estará vinculado al git commit que habremos hecho anteriormente

En línea de comando o shell, el uso del símbolo $ se utiliza para indicar que esa línea es la que se escribe en el terminal (normalmente te encontrarás ese símbolo, o en vscode la ruta donde estés), mientras que lo que no lleve el símbolo se refiere a la respuesta que te da el shell

Ojo, porque en según que cómandos git, en lugar de dar una respuesta lo que haremos es entrar en un editor con el que podremos hacer scroll para ver la respuesta, para salir de ese editor hay que utilizar la tecla q de quit

Git show

Una vez creado el tag después del commit, podremos explorar cualquier tag con git show donde veremos 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, formación en programación y marketing online",
"author": "KUWorking",
...

Aunque si no queremos almacenar esos cambios y sólo queremos guardar el tag en sí mismo y el mensaje, podemos hacer un tag lightweight (o tag ligero)

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

Los cambios siempre estarán presentes en el commit al que le podremos hacer igualmente un git show "commit..."

Cuando hacer el git tag?

El momento para hacer git tag es después del git commit o del git push

Pero si quieres hacerlo de un commit anterior, entonces necesitas su identificador, que lo encuentras

  • en github en tu historial de commits
  • en local haciendo un git log

Y así conseguirás un número no muy amigable tipo 0d52aaab4479697da7686c15f77a3d64d9165190 (esto debería convencerte de las bondades de utilizar tags)

De este número necesitas los últimos 6 o 7 carácteres, y procedes como antes, por ejemplo

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

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

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

Utilizando tags para package.json

Justamente para evitar el tener que lidiar con esa referencia numérica (un hash), los tags nos van perfectos para poder hacer algo así en nuestro package.json

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

Es decir, estamos instalando myPublicPackage no desde npm sino desde un repositorio git simplemente especificando el tag que queremos, sin tener que buscar el hash del commit que queramos

Y si el repositorio es privado, podemos hacer exactamente lo mismo siempre que pongamos el token que hayamos generado en github (que es la segunda línea del código de arriba)

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

El símil tonto sería poner etiquetas en los cables, si tienes uno es absurdo, si tienes cinco agradecerás poner esas etiquetas 👍

Qué tal la entrada?
👌 Bien 🙌🙌
👍 Bien, pero algunas cosas podrían explicarse mejor 😬
🤷‍♂️ Da por sentadas demasiadas cosas 😒
🤷‍♂️ A ver, hay poca chicha 😬
🤷‍♂️ Los ejemplos no son muy claros 🙇‍♂️
🤷‍♂️ No se entiende, está mal escrito 👎
✍️ Hay errores, revísalo en cuanto puedas 🙏

Quizá te interese

Privacidad
by kuworking.com
[ 2020 >> kuworking ]