Cómo verificar si un commit de Git es parte de una etiqueta

Introducción

En este laboratorio, aprenderás cómo determinar si un commit específico de Git está incluido en alguna de las etiquetas (tags) de tu proyecto. Esta es una habilidad valiosa para entender qué versiones o lanzamientos contienen cambios particulares.

A través de ejercicios prácticos, utilizarás el comando git tag --contains para identificar las etiquetas asociadas a un commit dado y explorar la funcionalidad de git describe para verificar las etiquetas. También probarás estos métodos con commits sin etiquetar para consolidar tu comprensión.

Skills Graph

%%%%{init: {'theme':'neutral'}}%%%% flowchart RL git(("Git")) -.-> git/BasicOperationsGroup(["Basic Operations"]) git(("Git")) -.-> git/BranchManagementGroup(["Branch Management"]) git/BasicOperationsGroup -.-> git/add("Stage Files") git/BasicOperationsGroup -.-> git/commit("Create Commit") git/BranchManagementGroup -.-> git/checkout("Switch Branches") git/BranchManagementGroup -.-> git/log("Show Commits") git/BranchManagementGroup -.-> git/tag("Git Tags") subgraph Lab Skills git/add -.-> lab-560062{{"Cómo verificar si un commit de Git es parte de una etiqueta"}} git/commit -.-> lab-560062{{"Cómo verificar si un commit de Git es parte de una etiqueta"}} git/checkout -.-> lab-560062{{"Cómo verificar si un commit de Git es parte de una etiqueta"}} git/log -.-> lab-560062{{"Cómo verificar si un commit de Git es parte de una etiqueta"}} git/tag -.-> lab-560062{{"Cómo verificar si un commit de Git es parte de una etiqueta"}} end

Ejecutar git tag --contains Commit

En este paso, aprenderemos cómo usar el comando git tag --contains para encontrar qué etiquetas (tags) contienen un commit específico. Esto es útil cuando quieres saber qué versiones o lanzamientos de tu proyecto incluyen un cambio particular.

Primero, asegúrate de estar en el directorio de tu proyecto. Abre tu terminal y navega hasta el directorio my-time-machine:

cd ~/project/my-time-machine

Ahora, creemos algunos commits y etiquetas para trabajar. Agregaremos un nuevo archivo y haremos un commit:

echo "Another message for the future" > message2.txt
git add message2.txt
git commit -m "Add a second message"

Deberías ver una salida similar a esta:

[master <commit-hash>] Add a second message
 1 file changed, 1 insertion(+)
 create mode 100644 message2.txt

Ahora, agreguemos una etiqueta a este commit. La llamaremos v1.0:

git tag v1.0

Este comando no produce ninguna salida, pero ha creado una etiqueta que apunta al último commit.

Hagamos otro commit sin etiqueta:

echo "A third message" > message3.txt
git add message3.txt
git commit -m "Add a third message"

Deberías ver una salida similar a esta:

[master <commit-hash>] Add a third message
 1 file changed, 1 insertion(+)
 create mode 100644 message3.txt

Ahora tenemos dos commits y una etiqueta. Usemos git log --oneline para ver el historial de commits:

git log --oneline

Deberías ver algo como esto (los hashes de los commits serán diferentes):

<commit-hash> (HEAD -> master) Add a third message
<commit-hash> (tag: v1.0) Add a second message
<commit-hash> Send a message to the future

Observa que la etiqueta v1.0 está asociada con el commit "Add a second message".

Ahora, encontremos qué etiquetas contienen el commit "Add a second message". Necesitamos el hash del commit para esto. Del resultado de git log --oneline, copia el hash del commit junto a (tag: v1.0).

Reemplaza <commit-hash> con el hash real que copiaste y ejecuta el siguiente comando:

git tag --contains <commit-hash>

Deberías ver v1.0 en la salida, porque esta etiqueta apunta directamente a ese commit.

Ahora, intentemos encontrar qué etiquetas contienen el primer commit ("Send a message to the future"). Copia el hash del commit de ese commit desde git log --oneline.

Reemplaza <first-commit-hash> con el hash real y ejecuta:

git tag --contains <first-commit-hash>

Todavía deberías ver v1.0 en la salida. Esto se debe a que v1.0 está en un commit que es un descendiente del primer commit. La opción --contains verifica si el commit especificado es un ancestro del commit al que apunta la etiqueta.

Este comando es muy útil cuando necesitas determinar qué versiones de tu software incluyen una corrección de error o una característica específica.

Usar git describe para Verificar Etiquetas

En este paso, exploraremos el comando git describe. Este comando se utiliza para encontrar la etiqueta (tag) más reciente que es alcanzable desde un commit. Es especialmente útil para generar nombres legibles por humanos para los commits, especialmente aquellos que no están directamente etiquetados.

Asegúrate de que todavía estés en el directorio ~/project/my-time-machine.

Primero, ejecutemos git describe sin ningún argumento:

git describe

Dado que nuestro último commit no está etiquetado, git describe buscará la etiqueta más cercana y luego nos dirá cuántos commits se han realizado desde esa etiqueta y proporcionará una versión corta del hash del último commit. Deberías ver una salida similar a esta:

v1.0-1-g<commit-hash>

Desglosemos esta salida:

v1.0: Esta es la etiqueta más reciente que es un ancestro del commit actual.
1: Esto indica que hay 1 commit entre la etiqueta v1.0 y el commit actual.
g<commit-hash>: La g significa "git" y <commit-hash> es un identificador único corto para el commit actual.

Este formato es muy útil para identificar versiones o compilaciones específicas de tu proyecto, incluso si no corresponden exactamente a una etiqueta.

Ahora, intentemos ejecutar git describe en el commit que tiene la etiqueta v1.0. Necesitamos el hash del commit "Add a second message". Puedes obtenerlo de git log --oneline.

Reemplaza <commit-hash-of-v1.0> con el hash real y ejecuta:

git describe <commit-hash-of-v1.0>

Esta vez, la salida debería ser simplemente:

v1.0

Esto se debe a que el commit especificado está directamente etiquetado con v1.0. Cuando el propio commit está etiquetado, git describe simplemente muestra el nombre de la etiqueta.

El comando git describe es una herramienta poderosa para entender la relación entre tus commits y tus etiquetas, ya que proporciona una forma concisa de nombrar los commits en función de su proximidad a la etiqueta más cercana.

Probar Commits Sin Etiquetar

En este paso, exploraremos más cómo se comporta git describe con commits que no están directamente etiquetados. Esto reforzará tu comprensión de cómo encuentra la etiqueta más cercana.

Asegúrate de estar en el directorio ~/project/my-time-machine.

Actualmente tenemos un commit después de la etiqueta v1.0. Hagamos otro commit:

echo "Yet another message" > message4.txt
git add message4.txt
git commit -m "Add a fourth message"

Deberías ver una salida similar a esta:

[master <commit-hash>] Add a fourth message
 1 file changed, 1 insertion(+)
 create mode 100644 message4.txt

Ahora, ejecutemos git describe de nuevo:

git describe

Esta vez, la salida debería ser similar a:

v1.0-2-g<commit-hash>

Observa que el número entre v1.0 y el hash del commit ahora es 2. Esto se debe a que ahora hay dos commits en la rama master desde que se creó la etiqueta v1.0. git describe cuenta correctamente el número de commits desde el commit etiquetado hasta el commit actual.

Este comportamiento es muy útil en las tuberías de integración y despliegue continuos, donde es posible que desees generar automáticamente nombres de versión para las compilaciones basadas en la etiqueta más reciente y el número de commits desde esa etiqueta.

Intentemos una cosa más. Crearemos una nueva rama y haremos un commit en esa rama.

git checkout -b feature/new-feature
echo "Feature file" > feature.txt
git add feature.txt
git commit -m "Add feature file"

Deberías ver una salida similar a esta:

Switched to a new branch 'feature/new-feature'
[feature/new-feature <commit-hash>] Add feature file
 1 file changed, 1 insertion(+)
 create mode 100644 feature.txt

Ahora, ejecuta git describe en esta nueva rama:

git describe

La salida todavía debería basarse en la etiqueta v1.0, pero la cuenta de commits y el hash serán diferentes:

v1.0-3-g<commit-hash>

Aunque estemos en una rama diferente, git describe todavía encuentra la etiqueta alcanzable más cercana, que en este caso es v1.0. La cuenta de commits 3 refleja el número de commits desde la etiqueta v1.0 hasta el commit actual en la rama feature/new-feature (los dos commits en master más el de la rama de característica).

Esto demuestra cómo funciona git describe en todas las ramas, siempre encontrando la etiqueta más cercana en el historial de commits.

Resumen

En este laboratorio, aprendimos cómo verificar si un commit de Git es parte de una etiqueta (tag) utilizando dos métodos principales. Primero, exploramos el comando git tag --contains <commit-hash>, que enumera directamente todas las etiquetas que incluyen el commit especificado. Esto es especialmente útil para identificar qué versiones o lanzamientos incorporan un cambio específico. Practicamos esto creando commits y etiquetas, luego utilizando git log --oneline para obtener los hashes de los commits y, posteriormente, realizando consultas con git tag --contains.

En segundo lugar, mencionamos brevemente el uso de git describe como otra forma de relacionar commits con etiquetas, aunque los pasos detallados para esto no se proporcionaron completamente en el extracto. El laboratorio también incluyó un paso para probar commits sin etiquetar, lo que reforzó la comprensión de cómo se comportan estos comandos cuando un commit no está asociado a ninguna etiqueta. En general, el laboratorio proporcionó experiencia práctica en el uso de comandos de Git para navegar y entender la relación entre commits y etiquetas en el historial de un proyecto.