¿Vuelve los cambios después de la extracción accidental?

El siguiente fue el estado de mi repository.

[~/rails_apps/jekyll_apps/nepalonrails (design)⚡] ➔ gst # On branch design # Changed but not updated: # (use "git add/rm <file>..." to update what will be committed) # (use "git checkout -- <file>..." to discard changes in working directory) # # modified: _layouts/default.html # deleted: _site/blog/2010/04/07/welcome-to-niraj-blog/index.html # deleted: _site/blog/2010/04/08/the-code-syntax-highlight/index.html # deleted: _site/blog/2010/05/01/showing-demo-to-kalyan/index.html # deleted: _site/config.ru # deleted: _site/index.html # deleted: _site/static/css/style.css # deleted: _site/static/css/syntax.css # modified: static/css/style.css # no changes added to commit (use "git add" and/or "git commit -a") 

Accedientemente, hice la git checkout -f y ahora los cambios se han ido, lo que se suponía que no debía hacer.

 [~/rails_apps/jekyll_apps/nepalonrails (design)⚡] ➔ git co -f [~/rails_apps/jekyll_apps/nepalonrails (design)] ➔ gst # On branch design nothing to commit (working directory clean) [~/rails_apps/jekyll_apps/nepalonrails (design)] ➔ 

¿Puedo recuperar los cambios?

No creo que pueda recuperar esos datos privados ("privados" como "no agregados en el índice, ni comprometidos", tan desconocidos para git), a less que tenga otro process de respaldo para su directory de trabajo actual.

Incluso si esto no se propone en la página Git Aliases , yo defendería un alias tipo para el pago (como el uso del alias rm /bin/rm -i ):

 [alias] co = !sh -c 'git stash; git stash apply; git checkout "$*"' 

, con el ' git stash; git stash apply ' git stash; git stash apply git stash; git stash apply 'siendo la' técnica de punto de control 'utilizada por Brian Campbell en su respuesta .

Este problema me restring un debate sobre este comportamiento en ycombinator (extractos):


He perdido bastantes datos con git.
La mayor parte tiene que ver con commands de sonido inocuo que no piden confirmación al eliminar datos .
Por ejemplo, el git checkout filename es equivalente a svn revert filename .
Por supuesto, el nombre de git checkout branchname hace algo completamente diferente.
Si una twig y un file comparten el mismo nombre, git cambiará de forma pnetworkingeterminada a las twigs, pero eso no impide que bash autocomplete arruine el día.

Aquí hay una idea loca: si tiene una acción inocua y una acción peligrosa, no los etiquete con el mismo command.


Molesto, tal vez, pero este es un error del usuario, no un error de layout. Con git, si quiero descartar sin pérdidas mi copy de trabajo, puedo simplemente " git stash ".
Según su lógica, "rm" tiene defectos porque no solicita confirmación cuando pasa -f lugar de -i . Bueno sí. Lo siento.


Su analogía sería más precisa si rm somename era el equivalente de apt-get update , y rm othername era rm -fr othername .
Aún así, no puede ser correcto que " get checkout foo " haga una de dos cosas COMPLETAMENTE diferentes dependiendo de si hay un file llamado foo en el directory actual o no.


Aquí hay otra idea loca: no ejecute ' git checkout ... ' en un tree de trabajo sucio. Problema resuelto.
Otro: no reutilice nombres de file como nombres de twigs.
Para ser sincero: tengo el mismo problema con las invocaciones descuidadas de ' rm ' arruinando mi día, pero cuando estoy murmurando maldiciones es en mi pereza / estupidez y no en terminaciones de bash o el comportamiento de ' rm '

Otra cosa que puedes ver es a través de tu IDE. Accidentalmente compré 2 files y pude recuperar los cambios a través de la "historia local" de mi IDE (netbeans). ¡Que bendición!

A less que hayas usado git add o git stash con esos files anteriormente, desafortunadamente no. Si los ha agregado o escondido, entonces debería poder encontrar sus git reflog hash a través de git reflog .

Nunca me he sentido cómodo con este comportamiento destructivo de git checkout . Quizás una mejora útil sería hacer que este tipo de git checkout de git checkout cree automáticamente un alijo (para que los files se capturen a través del reflog) antes de sobrescribir su trabajo.

Lo siguiente puede aplicarse en caso de que esté usando vim en Linux.

  • Si los files están abiertos en un búfer activo, entonces tiene el contenido del file, siempre y cuando no recargue el file en vim, y puede restaurarlo guardándolo. .

  • Si los files no están abiertos en un búfer activo, pero están sucios, entonces debe haber un file .swp en el directory de origen que también tenga una copy del contenido que sea recuperable mediante vim -r file.swp .

  • Si los files no están abiertos en el buffer antive o sucios, y si su copy de trabajo está en una partición ext3 o ext4, entonces extundelete podría encontrar los files .swp recientemente eliminados y / o una versión anterior de los files fuente. Reinstalar la partición como de solo lectura, por ejemplo, mount -o remount,ro /mnt/point , y ejecutar

     extundelete --recover-directory /path/to/working/copy /dev/sdaX 

    Si la partición que contiene la copy de trabajo es la partición raíz, puede negarse a volver a montarla, luego intente eliminar todos los services, y si todavía no funciona, apague y reinicie usando Live CD / USB / PXE, como GRML , y ejecute el encima. Logré recuperar uno de cada tres files perdidos de esta manera.

si usa Eclipse como IDE y EGit , tiene en su file el menu del Equipo:

  1. haga clic derecho en su file desde dentro
  2. Enumere el elemento "Equipo" -> "Mostrar historial local"

Verás toda la versión guardada localmente sin ningún nombre de guardado, en mi caso pero, puedes verificar fácilmente todos los cambios sin seguimiento de las características de Git y restaurar el código que falta.