LuisLlamas Logo
descartar-cambios-en-git-con-restore

Descartando cambios con Git Restore

  • 4 min
  • Intermedio

El comando git restore es el comando para descartar o deshacer cambios locales en el directorio de trabajo y sacar archivos del Staging Area.

Durante el desarrollo, a veces vas realizar modificaciones que finalmente no queremos conservar. Estás editando un archivo, empiezas a cambiar cosas, pruebas una idea loca y al final, no te gusta lo que has cambiado.

Ya sea porque estas haciendo pruebas o hayas has metido la pata, necesitamos una forma de revertir un archivo a su estado anterior. Necesitamos un “Ctrl+Z”, pero para Git.

En este artículo veremos cómo utilizar este git restore para descartar cambios en nuestro directorio de trabajo o sacar archivos del Staging Area.

Antiguamente esta tarea se realizaba con git checkout, un comando sobrecargado de funciones que solía generar confusión.

Para solucionar esto, las versiones modernas de Git introdujeron git restore.

Descartar cambios locales

Este es el caso más común. He roto el archivo, quiero volver atrás. No quieres tu versión acutal del fichero, quieres que vuelva a estar idéntico al último commit.

El comando es:

git restore nombre_archivo.ext
Copied!

También puedes usar . para restaurar todos los archivos modificados de la carpeta actual:

git restore .
Copied!

Git va a su base de datos (al último commit), busca esa versión del archivo y la copia en tu Working Directory, machacando lo que tuvieras escrito.

¡Cuidado! Esta operación es destructiva. A diferencia de otras cosas en Git, con restore no hay deshacer. Si restauras un archivo que no habías guardado con commit, los cambios que tuvieras escritos en él se pierden para siempre.

Restaurando desde el pasado

git restore no solo sirve para volver al “último” estado. Puedes traer un archivo tal y como estaba hace 5 meses.

Imagina que borraste una función en utils.js hace 10 commits y ahora la necesitas de vuelta. No hace falta revertir todo el proyecto. Puedes restaurar solo ese archivo desde un commit específico:

git restore --source c5f23a1 utils.js
Copied!
  • --source: Indica el hash del commit (o nombre de rama) desde donde queremos copiar.
  • utils.js: El archivo que queremos recuperar.

Esto traerá esa versión antigua del archivo a tu directorio de trabajo actual, listo para que lo uses.

El problema del antiguo git checkout

Si buscas tutoriales de Git anteriores a 2019, verás que para descartar cambios en un archivo te dicen que uses:

git checkout -- nombre_archivo.js
Copied!

El problema es que git checkout sufría de trastorno de personalidad múltiple. Hacía dos cosas totalmente distintas dependiendo de los argumentos:

  1. Si le dabas un nombre de rama: Cambiaba de rama.
  2. Si le dabas un nombre de archivo: Sobrescribía el archivo (descartando cambios).

Esto era peligroso. Un error al escribir el nombre de una rama podía llevarte a machacar archivos sin querer. Por eso, en la versión Git 2.23, decidieron partir este comando en dos más específicos:

  • git switch: Para cambiar de rama (lo veremos luego).
  • git restore: Para restaurar archivos (lo que vemos hoy).

git checkout sigue funcionando por compatibilidad hacia atrás y no va a desaparecer pronto. Pero, por semántica y seguridad, **te recomendamos encarecidamente usar git restore**.

Sacar archivos del Staging Area

Este es el otro uso principal de restore. Supongamos el siguiente caso:

  1. Modificas app.js (un cambio bueno).
  2. Modificas claves.txt (un archivo con contraseñas que NO quieres subir).
  3. Por inercia, escribes git add ..

Ahora tienes claves.txt en el Staging Area. Si haces commit, la lías, porque quedaría grabado en el histórico de Git.

Necesitas sacarlo del Stage, pero sin borrar el archivo de tu disco (porque quieres tu fichero de contraseñas).

git restore --staged claves.txt
Copied!

Al usar la bandera --staged, le estamos diciendo a Git: “Restaura la versión del archivo que hay en el Stage para que coincida con la del último commit”.

El resultado es que el archivo sale del área de preparación y vuelve a estar simplemente Modified (o Untracked si era nuevo).

Antiguamente esto se hacía con el críptico git reset HEAD claves.txt. Ahora, con restore, es mucho más lógico

En esta página