Etiquetar versiones importantes y revisar commits sin romper tu trabajo son dos tareas que en Git resuelves con Git Tag y Git Checkout. Aquí aprendes cómo usarlos juntos para marcar hitos en tu historial y explorar puntos previos sin afectar la rama principal, ideal si trabajas en equipo y necesitas control de versiones limpio.

¿Para qué sirve Git Tag en el control de versiones?

Git Tag te permite añadir una etiqueta a un commit específico para marcarlo como un hito. Piensa en una versión estable, una release alpha o cualquier punto que tu equipo quiera recordar con facilidad cuando navegue por el historial.

¿Qué es un tag en Git? Es una etiqueta que asocias a un commit para identificarlo con un nombre claro, como v1.0. No altera el historial ni los archivos, solo agrega un marcador visible en Git Log.

La lógica estricta diría que cada commit debería llevar tag, pero eso genera trabajo extra innecesario. Lo común es acordar con tu equipo en qué commits sí tiene sentido etiquetar: lanzamientos, milestones o versiones decimales acordadas.

¿Cómo crear un tag con mensaje?

Para crear una etiqueta anotada usas el comando con el flag -a y agregas un mensaje descriptivo con -m [01:30]:

bash git tag -a v1.0 -m "Mi primera versión"

Después de ejecutarlo, al correr git log verás junto a HEAD -> main la etiqueta v1.0 como un indicador del avance. Es como poner un separador en un libro largo: cuando tengas 100 o 200 commits, navegar entre tags es mucho más cómodo que recorrer todo el historial.

¿Cómo listar y ver detalles de un tag?

Si quieres ver únicamente la lista de etiquetas (no de commits), escribes:

• git tag lista todos los tags creados.
• git show v1.0 muestra autor, fecha, mensaje, commit asociado y los cambios realizados en ese commit.

Esto último es clave porque git show te entrega más información que un commit suelto: qué cambió, quién lo hizo y por qué. En historiales grandes esa narrativa pesa más que el hash.

¿Cómo elimino o corrijo un tag mal nombrado?

Si te equivocaste al nombrar la versión, puedes borrar el tag con el flag -d (delete) [03:45]:

bash git tag -d v1.0

Eliminar una etiqueta no altera commits, archivos ni el historial. Solo retira el marcador. Después puedes crear uno nuevo, por ejemplo git tag v2.0, y verificar con git log que el cambio quedó aplicado. Agregar o quitar etiquetas es una operación segura que no afecta el trabajo del resto del equipo.

¿Cómo uso Git Checkout para explorar commits anteriores?

Git Checkout no solo sirve para alternar entre ramas. También te deja viajar a un commit específico para evaluar cambios sin tocar main. Copias el hash del commit y ejecutas:

bash git checkout <hash>

Al entrar, Git te muestra una leyenda indicando que estás en estado detached HEAD. Si revisas con git log, notarás que HEAD ya no apunta a main con la flechita habitual. Estás ubicado en un punto temporal del historial.

¿Qué significa HEAD detached? Es cuando HEAD apunta a un commit específico en lugar de a una rama. Puedes editar y probar archivos, pero los cambios no afectan a main a menos que crees una rama nueva.

¿Puedo modificar archivos dentro de ese estado temporal?

Sí, y ahí está la magia. Si haces ls verás los archivos tal como existían en ese commit. Puedes crear nuevos, por ejemplo:

• Editas con nano testing3.txt y guardas el contenido.
• Verificas con git status que el cambio quedó registrado solo en ese espacio temporal.
• Pruebas qué pasa si tu sistema tiene o no ese archivo.

Todo ocurre en un sandbox aislado. Es ideal para experimentar sin riesgo de romper el proyecto principal.

¿Cómo regreso a main sin dejar rastro?

Cuando terminas tus pruebas, limpias la terminal y ejecutas [07:20]:

bash git checkout main

HEAD vuelve a apuntar a main y recuperas el estado original del proyecto, incluyendo el tag que ya tenías. Para confirmar que nada se alteró, corres git branch y verificas que no se creó ninguna rama nueva ni hubo modificaciones permanentes.

La ventaja es enorme: regresas a un commit previo, juegas con los archivos, validas hipótesis y, si no funciona, vuelves a la realidad donde todo está en orden. Cero consecuencias en el historial compartido.

¿Ya tienes claro en qué commits de tu proyecto pondrías un tag? Cuéntame en los comentarios cómo organizas las versiones con tu equipo.