7. Rollback: volver a una versión que funcionaba

Descripción

Al terminar esta lección vas a poder hacer lo que da sentido a todo el módulo: cuando un cambio rompa tu workflow, volver a una versión que funcionaba, de forma limpia, registrada y sin drama. Vas a saber usar git log para encontrar el commit bueno, vas a entender la diferencia entre git revert —deshacer un cambio dejando constancia, la vía segura— y git reset —mover el historial hacia atrás, potente y peligrosa—, con el criterio de cuándo usar cada una, y vas a recuperar la versión anterior de un solo archivo con git checkout <commit> -- archivo. En una frase: vas a convertir todo el historial que construiste en una red de seguridad de verdad.

Esto importa porque es la promesa que hizo la lección 1 hecha realidad. Recuerda el "martes malo" de Cumbre: alguien apuntó la consulta del CRM a la URL de pruebas, los pedidos mayoristas dejaron de enrutarse, y la diferencia entre resolverlo en diez minutos o a medianoche entre adivinanzas fue tener —o no— un historial que se pudiera recorrer hacia atrás. Todo lo que aprendiste hasta aquí —commits limpios, diffs legibles, ramas, respaldo en GitHub— existía para llegar a este momento: el momento en que algo sale mal y puedes volver atrás con precisión quirúrgica en lugar de con un JSON viejo y una plegaria.

Conexión con el módulo: esta lección cierra el ciclo de vida de un cambio que abrió la lección 1 —guardar, comparar, experimentar, compartir y, ahora, revertir—. Usa todo lo anterior: git log (lección 3) para encontrar el commit al que volver, git diff (lección 4) para confirmar qué cambió el commit sospechoso, y el respaldo en GitHub (lección 6) para entender por qué algunas formas de "volver atrás" son seguras en un repositorio compartido y otras no. Después de esta lección, el proyecto de la lección 8 solo junta todo lo que ya sabes en un entregable.

El valor real, frente a "tenía un JSON viejo por ahí"

Antes de los comandos, vale la pena nombrar con precisión qué te da Git que las copias manuales no. Porque tú ya podías "volver a una versión anterior" antes de Git: tenías order-triage-backup.json guardado en alguna carpeta. ¿Qué cambia?

Cambian tres cosas, y las tres importan el día del incidente.

Precisión. Con un backup manual, vuelves a "la versión de cuando hiciste el backup" —que puede ser de hace tres semanas y arrastrar la pérdida de todo lo bueno que hiciste desde entonces—. Con Git, vuelves a exactamente el commit que quieras, y puedes deshacer solo el cambio que rompió las cosas, conservando todos los demás. Es la diferencia entre amputar y operar con bisturí.

Trazabilidad. Un backup manual no deja rastro de por qué volviste ni de qué deshiciste. Git sí: revertir un cambio es, en sí mismo, un evento registrado en el historial, con su autor, su fecha y su nota. Dentro de un mes, cualquiera puede leer en el git log que ese cambio se deshizo y por qué. No hay misterio.

Confianza. Con backups manuales siempre queda la duda: "¿este era el bueno? ¿lo sobrescribí sin querer?". Con Git, cada commit es inmutable (lección 3): la versión que funcionaba el martes es, con certeza absoluta, la que git log señala. No hay ambigüedad posible.

Ese es el salto. No es "poder volver atrás" —eso ya lo tenías—. Es volver atrás con precisión, trazabilidad y confianza. Y eso solo lo da un historial de verdad.

Paso cero: encontrar el commit bueno

Cualquier rollback empieza igual: identificando a dónde quieres volver. La herramienta es git log, que ya conoces. Cuando algo se rompe, tu primer movimiento es leer el historial para ubicar el commit sospechoso y el último commit que funcionaba.

git log --oneline

Retomemos el escenario del "martes malo" de Cumbre. El historial se ve así:

7b2e105 (HEAD -> main) Point CRM lookup at the staging URL
a91c3f8 Add wholesale category to the order classifier
3e5d720 Widen CRM lookup timeout to 15 seconds
c08b4a2 Add order-triage workflow

El workflow se rompió y sospechas del commit de arriba, 7b2e105 Point CRM lookup at the staging URL. Antes de deshacer nada, confírmalo con un diff, para no revertir a ciegas:

# Compara el commit sospechoso con el anterior (~1 = "uno antes").
git diff a91c3f8 7b2e105

Leyendo ese diff con las reglas de la lección 4, ves que la única lógica que cambió fue la url del nodo Lookup Customer in CRM, que pasó del CRM de producción al de staging. Ahí está la causa, confirmada. Ahora sabes exactamente qué deshacer. La pregunta es cómo, y hay dos formas con filosofías opuestas.

git revert: deshacer dejando constancia (la vía segura)

La primera forma, y la que vas a usar el 90% del tiempo, es git revert.

git revert <commit> crea un commit nuevo que deshace los cambios de ese commit. No borra nada del historial: al contrario, agrega una foto nueva que es, en efecto, "lo contrario" del commit que señalaste. Si aquel cambió la URL de producción a staging, el revert la cambia de staging de vuelta a producción, y lo guarda como un commit más, arriba de todo.

La analogía es la de un libro de contabilidad. Imagina que anotaste por error un cobro de más. En un libro contable serio, no borras la línea equivocada —eso levantaría sospechas y perdería el rastro—. Lo que haces es escribir una línea nueva que anota el ajuste inverso, con una nota que dice "corrección del asiento anterior". El error queda visible, y también queda visible su corrección. La cuenta final es correcta, y cualquiera puede auditar qué pasó. git revert es esa línea de corrección: el error sigue en la historia, pero también está, justo debajo, su enmienda registrada.

Por eso git revert es la vía segura, especialmente cuando tu trabajo ya está compartido en GitHub. Como no altera la historia pasada —solo le agrega algo nuevo—, no entra en conflicto con las copias que otros ya tienen. Deshaces el error sin reescribir el pasado que tu equipo comparte.

Ejemplo trabajado: revertir el cambio que rompió order-triage

Paso 1 — Parte de un árbol limpio y confirma dónde estás.

git status

Debe decir On branch main y nothing to commit, working tree clean.

Paso 2 — Revierte el commit culpable. Como el commit malo es el último (HEAD), puedes referirte a él por su folio o simplemente como HEAD:

git revert HEAD

Qué esperar. Git va a abrir tu editor de texto con un mensaje de commit ya escrito para ti, algo así:

Revert "Point CRM lookup at the staging URL"

This reverts commit 7b2e105...

Ese mensaje automático es bueno tal cual —describe exactamente qué hace el commit—. Guárdalo y cierra el editor para confirmar. (Si te tocó Vim como editor y no sabes salir: presiona Esc, luego escribe :wq y Enter, que significa "guardar y salir". Y si prefieres evitar el editor del todo, existe git revert --no-edit HEAD, que usa el mensaje automático sin abrir nada.)

Tras confirmar, Git responde:

[main d4f9a1c] Revert "Point CRM lookup at the staging URL"
 1 file changed, 1 insertion(+), 1 deletion(-)

Paso 3 — Lee el historial y comprueba la limpieza.

git log --oneline

d4f9a1c (HEAD -> main) Revert "Point CRM lookup at the staging URL"
7b2e105 Point CRM lookup at the staging URL
a91c3f8 Add wholesale category to the order classifier
3e5d720 Widen CRM lookup timeout to 15 seconds
c08b4a2 Add order-triage workflow

Mira lo que pasó, porque es exactamente el bloque con el que abrimos la lección 1. El commit malo 7b2e105 sigue ahí —la historia no se falsificó—, y encima de él aparece d4f9a1c Revert "...", la corrección registrada. Tu order-triage.json en la carpeta ya volvió a apuntar el CRM a producción; el workflow funciona de nuevo. Y el historial cuenta la verdad completa: se cometió un error, y se corrigió, con fecha y autor. Eso es cerrar un incidente con trazabilidad.

Paso 4 — Comparte la corrección. Como tu equipo trabaja sobre el remoto (lección 6), sube el revert para que todos tengan el arreglo:

git push

Y ya está. El "martes malo" de Cumbre, resuelto en cinco comandos y sin haber tocado un solo backup manual.

Cierra el lazo con n8n. Un detalle que no conviene saltarse: revertir en Git arregla el archivo, pero el workflow que corre en tu instancia de n8n es el que importaste, no el archivo del repositorio. Para que el arreglo llegue a producción, tienes que importar de vuelta el order-triage.json corregido a n8n y publicarlo. Git es la fuente de la verdad del historial; n8n es donde el workflow efectivamente corre. El rollback en Git es el primer paso —recuperar la versión buena de forma auditable—; llevarla a n8n es el segundo. Cómo promover un workflow de un lado a otro con orden es tema de los módulos 4 a 6; por ahora quédate con que un revert limpio en Git no es el final, sino el archivo bueno listo para volver a la plataforma.

Recuperar un solo archivo de una versión anterior

A veces no quieres revertir un commit entero, sino recuperar cómo estaba un archivo específico en cierto punto del pasado. Por ejemplo: exploraste varios cambios sin commitear y quieres volver tu order-triage.json a como estaba en el primer commit, sin tocar nada más. Para eso está git checkout con la forma de archivo:

# Trae la versión de order-triage.json que había en el commit c08b4a2.
git checkout c08b4a2 -- order-triage.json

Qué esperar. El silencio del éxito. Pero por dentro, Git tomó la versión de order-triage.json que existía en el commit c08b4a2 y la puso en tu carpeta y en tu área de preparación, reemplazando lo que tuvieras. Los guiones dobles -- antes del nombre son importantes: le dicen a Git "lo que sigue es un nombre de archivo, no una rama" (evitan una ambigüedad si tuvieras una rama con el mismo nombre que un archivo).

Fíjate en lo que este comando no hizo: no movió HEAD, no cambiaste de rama, no tocó ningún otro archivo. Solo trajo un archivo de una foto vieja al presente. Confírmalo:

git status

On branch main
Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
	modified:   order-triage.json

Git ve el archivo recuperado como una modificación ya preparada —porque checkout lo dejó en el árbol de trabajo y en el área de preparación a la vez—. Ahora ese archivo está listo para que lo revises y, si te convence, lo guardes con un commit normal:

git commit -m "Restore order-triage to its first-commit version"

Así queda registrado que recuperaste esa versión, con su nota y su fecha —la trazabilidad de la que hablamos al principio—. Recuperar el archivo es la mitad del trabajo; guardar la recuperación es la otra mitad.

Una nota sobre nombres: Git moderno también ofrece git restore --source=c08b4a2 order-triage.json, que hace lo mismo de forma más explícita y es el comando "nuevo" (parte de la misma reforma de 2019 que trajo git switch). Los dos funcionan; checkout es el que más vas a ver en material existente, restore es el más claro. Con cualquiera recuperas un archivo de una versión anterior.

Deshacer antes de commitear: descartar cambios sueltos

No todo rollback es sobre commits ya guardados. Un caso muy común es más humilde: estabas editando order-triage, hiciste unos cambios en el archivo, y te diste cuenta de que fue un mal camino —quieres volver a como estaba el archivo en tu último commit, tirando lo que llevas—. Todavía no commiteaste nada, así que no hay commit que revertir. Lo que quieres es descartar cambios sueltos del árbol de trabajo.

La herramienta es git restore:

# Descarta los cambios sin guardar de order-triage.json,
# devolviéndolo a como estaba en el último commit.
git restore order-triage.json

Qué esperar. El silencio del éxito, y tu archivo de vuelta a como estaba en el último commit. Ojo, porque esto es una advertencia seria: git restore sobre un archivo descarta tus cambios sin guardar y no hay papelera. Lo que no habías commiteado ni preparado, se pierde. Por eso Git te lo recuerda cada vez que corres git status y ves un archivo modificado: entre las sugerencias aparece (use "git restore <file>..." to discard changes in working tree), con la palabra discard (descartar) bien clara.

Hay una variante hermana para cuando ya hiciste git add pero te arrepentiste de haber preparado el archivo —no de los cambios, solo de haberlos metido al encuadre—:

# Saca order-triage.json del área de preparación, SIN perder los cambios.
git restore --staged order-triage.json

Esto último es suave y reversible: solo devuelve el archivo del área de preparación al árbol de trabajo, sin tocar tus cambios. Es el "deshacer" del git add. La diferencia entre las dos formas es importante y vale la pena grabarla: git restore --staged archivo quita del encuadre pero conserva tus cambios; git restore archivo (sin --staged) descarta tus cambios sin guardar. Una es reversible, la otra no. Ante la duda con la segunda, primero mira con git diff qué vas a perder.

Con esto tienes el mapa completo de "deshacer" según en qué zona vive lo que quieres deshacer, que es, de nuevo, el modelo de tres zonas de la lección 2: cambios sueltos en el árbol de trabajo se descartan con git restore archivo; cambios preparados se sacan del encuadre con git restore --staged archivo; y commits ya guardados se deshacen con git revert (seguro) o git reset (local y con cuidado).

git reset: mover el historial hacia atrás (potente y peligrosa)

Llegamos a la herramienta que hay que tratar con respeto. git revert agrega una corrección; git reset hace algo distinto y más drástico: mueve el puntero de tu rama hacia atrás, como si los commits posteriores no hubieran existido.

Recuerda de la lección 5 que una rama es un puntero móvil a un commit. git reset <commit> agarra ese puntero y lo mueve al commit que le indiques, dejando "huérfanos" los commits que estaban después. Es decir, reescribe la historia de tu rama: los quita de la línea.

Vuelve a la analogía del libro contable. Si revert era escribir una línea de corrección, reset es arrancar la página con el error. La cuenta puede quedar bien, pero destruiste el registro de lo que pasó —y si alguien más tenía una copia de esa página, ahora tu libro y el suyo no coinciden—.

reset tiene tres modos, según qué hace con tus cambios al mover el puntero:

• git reset --soft <commit>: mueve el puntero, pero conserva todos tus cambios en el área de preparación, listos para rehacer un commit. El más suave.
• git reset --mixed <commit> (el modo por defecto): mueve el puntero y conserva tus cambios en el árbol de trabajo, pero sin preparar. Los archivos quedan tocados, tú decides qué hacer.
• git reset --hard <commit>: mueve el puntero y descarta todos los cambios posteriores, en preparación y en árbol de trabajo. Los tira. Es el más potente y el más peligroso: el trabajo que descarta no es fácil de recuperar.

¿Cuándo se usa reset, entonces? En un caso concreto y local: cuando hiciste un commit que todavía no compartiste con nadie y quieres deshacerlo como si nunca hubiera pasado —por ejemplo, un commit con un mensaje vergonzoso o con algo que no debía entrar—. Como nadie más tiene ese commit, reescribir tu historia local no rompe nada de nadie.

La regla de oro, la que no debes romper: nunca uses git reset sobre commits que ya empujaste a un remoto compartido. Si ya hiciste git push de un commit y luego lo borras con reset, tu historia local y la del remoto —y las de tus compañeros— dejan de coincidir, y arreglarlo es un lío que puede hacer perder trabajo al equipo. Para deshacer algo ya compartido, siempre git revert, que agrega en vez de reescribir. La distinción es simple y salva de muchos problemas: revert para lo compartido, reset solo para lo que todavía es tuyo y de nadie más.

Como esta guía te enseña el Git del ciclo de vida de un workflow y ese ciclo casi siempre pasa por un remoto compartido, la práctica que te llevas es: usa revert por defecto. reset está aquí para que lo entiendas y lo reconozcas, no para que sea tu herramienta diaria.

La red de emergencia: git reflog

Vale la pena conocer una última herramienta, no para el uso diario sino para el día del susto: git reflog. La menciono porque saber que existe puede salvarte de creer que perdiste trabajo para siempre.

Cada vez que HEAD se mueve —cada commit, cada cambio de rama, cada reset, cada merge— Git anota en secreto por dónde estuvo, en un registro local llamado reflog (de reference log). Ese registro no es tu historial de commits; es una bitácora privada de tus movimientos, incluso los que "borraron" cosas.

git reflog

Qué esperar. Una lista de los movimientos recientes de HEAD, cada uno con su folio:

d4f9a1c (HEAD -> main) HEAD@{0}: revert: Revert "Point CRM lookup at the staging URL"
7b2e105 HEAD@{1}: commit: Point CRM lookup at the staging URL
a91c3f8 HEAD@{2}: commit: Add wholesale category to the order classifier
3e5d720 HEAD@{3}: commit: Widen CRM lookup timeout to 15 seconds

¿Para qué sirve esto en un rollback? Imagina que hiciste un git reset --hard de más y "perdiste" un commit que sí querías. Ese commit no aparece en git log —lo sacaste de la línea— pero sí sigue en el reflog, con su folio. Con ese folio puedes volver a él (por ejemplo, git checkout <folio> para inspeccionarlo, o crear una rama nueva que lo rescate con git switch -c rescate <folio>). Es la razón por la que dije que reset --hard descarta trabajo de forma "casi" irrecuperable, no del todo: el reflog es esa red debajo.

Dos límites honestos para que no descanses demasiado en ella. Primero, el reflog es local: vive solo en tu máquina, no se comparte ni se clona; si el problema es en otra copia, su reflog es el que importa. Segundo, el reflog caduca: Git limpia las entradas viejas después de un tiempo (por defecto, semanas o meses según el tipo). No es un archivo eterno. Por eso sigue siendo mejor no meterte en el apuro —usar revert en vez de reset --hard— que confiar en rescatarte después. Pero si el apuro ya pasó, respira: git reflog es lo primero que hay que mirar antes de dar algo por perdido.

Errores comunes

Usar git reset --hard sobre trabajo que no querías perder (práctico y serio). Qué pasa: para "limpiar" cambios se corre git reset --hard y desaparecen commits o modificaciones que en realidad sí importaban, sin una papelera evidente de dónde sacarlos. Por qué pasa: --hard suena a "resetear y ya", y no es obvio que descarta trabajo de forma casi irrecuperable. Cómo detectarlo: si después de un reset --hard te falta algo, es esto —y el susto es real—. Cómo corregirlo: antes de cualquier reset --hard, pregúntate si hay algo ahí que quieras conservar; si dudas, no lo uses. Existe una red de emergencia poco conocida —git reflog, un registro de por dónde ha estado HEAD, que a veces permite recuperar commits que creías perdidos— pero no cuentes con ella: la mejor defensa es no usar --hard a la ligera. Para deshacer sin destruir, usa revert.

Confundir revert y reset (conceptual). Qué pasa: se quiere deshacer un cambio ya compartido y se usa reset, reescribiendo una historia que otros ya tenían y provocando divergencias entre las copias del equipo. O al revés: se quiere limpiar un commit local privado y se usa revert, dejando dos commits (el error y su corrección) donde bastaba con borrar uno. Por qué pasa: los dos "deshacen", pero de formas opuestas —uno agrega, otro reescribe— y es fácil mezclarlos. Cómo detectarlo: pregúntate "¿este commit ya lo empujé al remoto?". Si sí, reset es peligroso. Cómo corregirlo: memoriza la regla —revert para lo compartido (agrega una corrección, seguro), reset solo para lo local y privado (reescribe, riesgoso)—. Ante la duda, revert nunca te mete en un problema de historia divergente.

Revertir sin confirmar primero qué hizo el commit (práctico). Qué pasa: algo se rompe, se culpa al último commit y se revierte de inmediato, pero el commit revertido no era la causa —o traía además un cambio bueno que ahora también se deshizo—. Por qué pasa: la prisa del incidente empuja a actuar antes de diagnosticar. Cómo detectarlo: si tras revertir el problema sigue, o aparece uno nuevo, quizás revertiste el commit equivocado. Cómo corregirlo: antes de revertir, confirma con git diff <anterior> <sospechoso> que ese commit contiene el cambio que rompió las cosas, y solo ese. Diagnostica con el diff, luego actúa. Y si un commit mezcla un cambio bueno con uno malo, esa es justamente la razón por la que la lección 3 insistía en un commit por idea: los commits atómicos se revierten sin daño colateral.

Recuperar un archivo viejo y creer que "ya volviste atrás" sin commitear (práctico). Qué pasa: se recupera una versión anterior de order-triage.json con git checkout <commit> -- archivo, se prueba, funciona, y se da por cerrado el asunto —pero nunca se hizo el commit, así que el historial no registra la recuperación y el remoto no la tiene—. Por qué pasa: como el archivo ya está bien en la carpeta, se siente terminado. Cómo detectarlo: git status muestra el archivo recuperado bajo "Changes to be committed" o "not staged"; si sigue ahí, no lo guardaste. Cómo corregirlo: después de recuperar y verificar, haz el ciclo normal —git add, git commit con una nota clara ("Restore order-triage to the pre-staging-url version"), y git push—. Recuperar el archivo es la mitad; registrar la recuperación en la historia es la otra mitad, y es la que le da trazabilidad.

Ejercicios

Ejercicio 1 — Revierte un cambio de principio a fin. En tu repositorio, haz un cambio a order-triage que sepas que es "malo" (por ejemplo, cambia el path del webhook a algo incorrecto), exporta, y guárdalo con un commit Change webhook path to order-intake. Luego, imagina que rompió la entrada de pedidos: confírmalo con un git diff contra el commit anterior, revierte el commit malo con git revert, y verifica con git log --oneline que quedan los dos commits (el malo y su revert) y que tu archivo volvió al path correcto.

# (haces el cambio malo en n8n y reemplazas el archivo)
git add order-triage.json
git commit -m "Change webhook path to order-intake"

# diagnóstico: confirma qué cambió el commit malo
git diff HEAD~1 HEAD

# la corrección
git revert HEAD          # guarda el mensaje automático, o usa --no-edit

git log --oneline        # ves el commit malo Y su revert encima

Ejercicio 2 — Elige la herramienta correcta. Para cada situación, di si usarías git revert, git reset o git checkout <commit> -- archivo, y por qué.

(a) Un commit que ya empujaste a GitHub y que tu compañera ya bajó resultó estar mal; hay que deshacerlo. (b) Acabas de hacer un commit local, aún no lo empujaste a ningún lado, y te diste cuenta de que el mensaje tiene un error grave y prefieres rehacerlo desde cero. (c) Quieres recuperar cómo estaba únicamente order-triage.json hace tres commits, sin tocar el resto del proyecto ni deshacer commits.

Ejercicio 3 — Razona el peligro de reset en un remoto. Explica con tus palabras, en tres o cuatro frases, por qué usar git reset --hard sobre un commit que ya empujaste a GitHub y que un compañero ya bajó es una mala idea, y qué deberías usar en su lugar.

Resumen y siguiente paso

En esta lección convertiste tu historial en una red de seguridad real. Viste que el valor de Git frente a "tenía un JSON viejo por ahí" no es "poder volver atrás" —eso ya lo tenías— sino volver atrás con precisión (al commit exacto, deshaciendo solo lo que rompió), trazabilidad (la reversión queda registrada con autor y fecha) y confianza (cada commit es inmutable, no hay ambigüedad sobre cuál era el bueno). Aprendiste a encontrar el commit al que volver con git log y a confirmar la causa con git diff antes de actuar. Dominaste las dos filosofías de deshacer: git revert, que agrega un commit de corrección sin tocar el pasado —la línea de ajuste en el libro contable, segura para lo compartido— y git reset, que mueve el puntero de la rama hacia atrás reescribiendo la historia —arrancar la página, potente y reservada solo para commits locales que nadie más tiene—, con la regla de oro: revert para lo compartido, reset solo para lo privado. Y recuperaste un solo archivo de una versión anterior con git checkout <commit> -- archivo. Cerraste el "martes malo" de Cumbre en cinco comandos.

Antes de avanzar a la lección 8 deberías poder: revertir un commit y explicar por qué el commit malo sigue en la historia; decir cuándo reset es seguro y cuándo es peligroso; y recuperar la versión anterior de un archivo sin tocar el resto del proyecto.

Con esto tienes el ciclo completo. Sabes instalar Git, crear un repositorio, hacer commits limpios, leer diffs a través del ruido del JSON, experimentar en ramas, respaldar y compartir en GitHub, y volver atrás cuando algo se rompe. La lección 8 no introduce nada nuevo: es el proyecto que junta todo. Vas a tomar order-triage, ponerlo bajo control de versiones de punta a punta, iterar en tres ramas distintas, revisar sus diffs, fusionar a main, revertir un cambio concreto y conectarlo a un remoto en GitHub. El entregable —un repositorio con historial legible y un cambio revertido con limpieza— es exactamente lo que el mercado pide cuando dice "version-controlled JSON", y es la prueba, defendible en una entrevista, de que cruzaste la frontera de constructor de workflows a dueño del sistema.

Recursos

• Undoing Things — Git Docs — el capítulo del libro oficial sobre deshacer cambios, incluyendo la recuperación de archivos y las trampas del reset.
• git revert — Git Docs — la referencia del comando que deshace un commit agregando otro, la vía segura para lo compartido.
• git reset — Git Docs — la referencia del comando que mueve el puntero de la rama, con la explicación de los modos --soft, --mixed y --hard. Léela con la regla de oro en mente.
• Reset Demystified — Git Docs — un capítulo dedicado a entender reset a fondo, con diagramas de qué toca cada modo. Útil cuando quieras dejar de temerle a base de entenderlo.
• git checkout — Git Docs — la referencia del comando, incluyendo la forma git checkout <commit> -- <archivo> para recuperar un archivo de una versión anterior.