Git: recupera un cambio sin perder tu trabajo

1. Construye un laboratorio aislado

Abre Bash y elige una carpeta de prácticas fuera de OneDrive o Dropbox. Crea una carpeta nueva con un nombre que no exista; si mkdir falla, detente y elige otro nombre. Ejecuta cada bloque desde el mismo terminal. Los nombres y correos siguientes son ficticios y se guardan solo en este repositorio.

mkdir labs-git-rescate
cd labs-git-rescate
git init -b main
git config user.name 'Alumno Labs'
git config user.email 'alumno@example.invalid'
printf 'Versión inicial\n' > notas.txt
git add notas.txt
git commit -m 'Crea las notas iniciales'
git status --short

Comprueba: Git confirma el primer commit. El último comando no muestra líneas: no quedan cambios pendientes. El identificador del commit varía en cada equipo.

2. Antes de deshacer, mira dónde está el cambio

Git tiene un archivo de trabajo, una zona de preparación (index) y un historial de commits. status indica dónde está cada cambio; diff permite inspeccionarlo. Añade una línea y observa antes de modificar nada más.

printf 'Idea pendiente\n' >> notas.txt
git status --short
git diff
git add notas.txt
git diff --cached

Comprueba: Primero aparece « M notas.txt»: cambiado en el archivo de trabajo. Después de add, diff --cached muestra la línea preparada para el próximo commit. add todavía no crea ese commit.

3. Saca un archivo de la preparación y conserva su contenido

Si preparaste algo antes de tiempo, restore --staged lo retira del index. No borra la edición del archivo de trabajo. Este es el primer recurso ante un add accidental.

git restore --staged notas.txt
git status --short
cat notas.txt

Comprueba: Vuelve a aparecer « M notas.txt» y cat conserva «Idea pendiente». No has perdido la edición.

4. Conserva una copia antes de descartar una edición

Solo en este laboratorio, copia el archivo fuera del repositorio antes de descartar el cambio local. Si cp pregunta si quieres reemplazar una copia existente, responde que no y usa otro nombre de copia. git restore -- notas.txt sustituye su contenido por la versión del index: puede destruir cambios que nunca se guardaron en un commit. No lo uses como solución genérica en un proyecto real.

cp -i notas.txt ../labs-git-rescate-copia.txt
git diff -- notas.txt
git restore -- notas.txt
cat notas.txt
cat ../labs-git-rescate-copia.txt

Comprueba: El archivo del repositorio vuelve a tener una línea. La copia externa mantiene ambas. Conservar una copia es lo que hace recuperable esta edición; Git no promete rescatar cualquier texto descartado.

5. Deshaz un commit conservando el historial

Ahora introduce y confirma una línea. revert crea otro commit que invierte el cambio: es una opción habitual cuando el commit ya se compartió. No equivale a borrar el historial. La práctica parte de un estado limpio y no genera conflictos; en un proyecto real pueden aparecer y deben revisarse.

printf 'Cambio que voy a revertir\n' >> notas.txt
git add notas.txt
git commit -m 'Añade una idea experimental'
git revert --no-edit HEAD
git log --oneline -3
cat notas.txt

Comprueba: Hay tres commits: inicial, experimental y reversión. El archivo vuelve al contenido inicial.

Tu turno

Crea otro commit que añada «Segundo experimento». Reviértelo sin borrar commits. Antes de cada operación escribe qué esperas que cambie: el archivo, el index o el historial.

printf 'Segundo experimento\n' >> notas.txt
git add notas.txt
git commit -m 'Añade el segundo experimento'
git revert --no-edit HEAD
git log --oneline -5
git status --short

Explícalo con tus palabras

• ¿Por qué add no basta para guardar una versión en el historial?
• ¿Qué copia permite recuperar la línea descartada en el paso 4?
• ¿Qué ventaja aporta revert cuando otras personas ya tienen el commit?

Repite con datos distintos antes de marcarlo como practicado. Esta es una autoevaluación, no una certificación.