Recomiendo desaprender git reset. No necesita ese comando y es peligroso, así que no lo use. Para devolver la rama a la confirmación anterior, git rebase -isuelte las confirmaciones que no desea o git checkout(separa la cabeza) y luego git branch -Mmueva la punta de la rama. El primero se negará a ejecutarse con cambios locales y el último solo se ejecutará si los archivos modificados localmente no difieren entre las revisiones.
Jan Hudec
11
@ Jan No lo creo. Hay razones perfectamente legítimas para usar reset.
spaaarky21
44
@ spaaarky21: Sí, los hay. Pero git reset --hard somewherees uno de los pocos comandos git realmente peligrosos.
Jan Hudec
55
@ Jan Estoy de acuerdo, pero ser peligroso no significa que no debas usarlo. Solo sepa lo que está haciendo y tenga cuidado. :)
No puede recuperar los cambios no confirmados en general.
Los cambios organizados previamente ( git add) deben ser recuperables de los objetos de índice, por lo tanto, si lo hizo, use git fsck --lost-foundpara ubicar los objetos relacionados con él. (Esto escribe los objetos en el .git/lost-found/directorio; desde allí puede usar git show <filename>para ver el contenido de cada archivo).
Si no, la respuesta aquí sería: mira tu copia de seguridad. Quizás su editor / IDE almacene copias temporales en / tmp o C: \ TEMP y cosas así. [1]
git reset HEAD@{1}
Esto restaurará a la CABEZA anterior
[1] vim, por ejemplo, opcionalmente almacena deshacer persistente, eclipse IDE almacena el historial local ; tales características podrían guardar su **
El historial local de Eclipse, y además, dado que algunos cambios fueron anteriores a 6 días, ¡mi copia de seguridad de Time Machine del historial local de Eclipse! Por alguna razón, la copia de seguridad de Time Machine de la carpeta administrada por git no contenía mis cambios anteriores.
christianbrodbeck
2
¡Eres un verdadero salvavidas en la pista! El TextWrangler tenía una copia de seguridad de los archivos. Gracias
Vivek Sampara
66
El IDE (IntelliJ) almacenó los cambios localmente que salvaron el día. ¡Gracias por el consejo!
progonkpa
1
Wow esto es increíble. Funciona incluso si nunca se ha comprometido.
Boudewijn Aasman
2
De hecho, la historia local en Eclipse (Intellij en mi caso) me salvó el día en la recuperación de cambios sin importancia, documento aquí para Intellij: blog.jetbrains.com/idea/2008/01/…
$ git reflog show
93567ad HEAD@{0}: reset: moving to HEAD@{6}
203e84e HEAD@{1}: reset: moving to HEAD@{1}
9937a76 HEAD@{2}: reset: moving to HEAD@{2}
203e84e HEAD@{3}: checkout: moving from master to master
203e84e HEAD@{4}: reset: moving to HEAD~1
9937a76 HEAD@{5}: reset: moving to HEAD~1
d5bb59f HEAD@{6}: reset: moving to HEAD~1
9300f9d HEAD@{7}: commit: fix-bug
# said the commit to be recovered back is on 9300f9d (with commit message fix-bug)
$ git reset HEAD@{7}
Solo para agregar a esta respuesta, esto ayudaría a las personas que realmente habían cometido cambios que se descartaron a través del restablecimiento completo.
murki
99
Genial, pero en mi caso los archivos desaparecieron por completo. El uso git checkout HEAD@{19}me permitió revisar los archivos perdidos en un estado separado. Luego solía git checkout -b new-branch-nameagregarlos nuevamente al repositorio en estado "adjunto".
NightOwl888
@ NightOwl888: Git novato aquí y tuve el mismo problema que mis archivos aún no estaban. ¿Podría explicar con más detalle cómo ha recuperado sus archivos en un estado "adjunto" (o podría explicar lo que eso realmente significa)? Muchas gracias!
OhDaeSu
3
@ user3385759 - En Git, cuando usas el comando de pago en cualquier cosa que no sea una rama, entrará en un modo especial de "cabeza separada". Esto significa que en realidad no está apuntando a una rama, pero puede ver lo que se registró en el estado de la entidad (en este caso, una entrada de registro). Desde ese estado, puede convertirlo en una rama "real" a la que puede volver utilizando nuevamente git checkout -b new-branch-name. El libro Pragmatic Version Control Using Git es bueno para explicar Git en términos simples.
NightOwl888
2
Sí, lo que dijeron NomNomCameron y Jesse Adelman. Pensé erróneamente que el restablecimiento se restablecería a mi último commit. No Se borró todo. Esta respuesta me salvó de uno o dos días de volver a crear mi trabajo.
VeteranCoder
308
Accidentalmente corrí git reset --harden mi repositorio hoy también mientras tenía cambios sin confirmar también hoy. Para recuperarlo, ejecuté git fsck --lost-found, que escribió todos los blobs sin referencia <path to repo>/.git/lost-found/. Como los archivos no estaban confirmados, los encontré en el otherdirectorio dentro de <path to repo>/.git/lost-found/. A partir de ahí, puedo ver los archivos no confirmados usando git show <filename>, copiar los blobs y cambiarles el nombre.
Nota: Esto solo funciona si agregó los archivos que desea guardar en el índice (usando git add .). Si los archivos no estaban en el índice, se pierden.
Tengo solo archivos con referencias de confirmación lost-found. Pero entonces podría hacer git showpara obtener contenidos.
Mitar
66
Solo para ahorrarle tiempo a cualquiera#!/bin/bash cd PATH_TO_PROJECT/.git/lost-found/other FILES=* COUNTER = 0 for f in $FILES do echo "Processing $f file..." git show $f > "PATH_TO_RECOVERY_DIRECTORY/$COUNTER.m" let COUNTER=COUNTER+1 done
rwolst
209
Sí, PUEDE RECUPERARSE de un restablecimiento completo en git.
Utilizar:
git reflog
para obtener el identificador de su confirmación. Luego use:
Hasta ahora, creo que esta es la mejor y más concisa respuesta. Puede parecer contradictorio recuperarse del git reset --harduso de otro, git reset --hardpero si no usa el --hardinterruptor, se le dejarán entradas en su espacio de trabajo que revertirán efectivamente el trabajo que acaba de recuperar.
Esta respuesta no es correcta. Este enfoque solo recupera los cambios previamente comprometidos . No podrá restaurar los cambios no confirmados (de eso se trata esta pregunta).
Alderath
2
Esta solución me funciona. Hice un restablecimiento completo y luego, cuando lo uso git log, no vi la identificación de la confirmación. Con git reflogpude ver la ID de confirmación
dboscanv
2
esto funciona para mi ¡¡¡¡¡¡Gracias!!!!!!
RedEyed
60
Mientras trabajaba en un proyecto local, quería moverlo a GitHub y luego crear un nuevo repositorio. Mientras intentaba agregar todos estos archivos al nuevo repositorio con .gitignore, accidentalmente agregué un archivo incorrecto y luego traté de borrarlo.
Corrí git reset --hard origin/master: P
Luego, todos mis archivos locales se eliminaron porque el repositorio estaba vacío. Pensé que todo se había ido.
Tengo 7 confirmaciones para restablecer, utilizo git reflog showpara verificar y desde esa primera confirmación utilizogit reset HEAD@{number}
Vishwas Nahar
38
Si usa algo como IntelliJ:
En el menú contextual, elija Historial local y haga clic en Mostrar historial en el submenú:
La vista del historial local de un proyecto o carpeta le muestra todo lo que ha hecho durante los últimos días. En la columna Acción de la parte inferior del cuadro de diálogo, seleccione la acción que desea revertir. [...] Al hacerlo, la parte superior del cuadro de diálogo muestra la vista de árbol de los archivos modificados. Si solo desea restaurar el archivo eliminado, independientemente de los otros cambios que se hayan realizado desde entonces, puede seleccionar el archivo Lost.txt en la vista de árbol y hacer clic en el botón Revertir.
¡Esta es, de lejos, la mejor respuesta para los usuarios de IntelliJ! Muchas gracias, esto funcionó perfectamente. Intenté con cualquier otra solución y ninguna funcionó bien. git reflogno funcionó porque no cometí los cambios. git fsck --lost-foundfuncionó para archivos organizados pero no todos fueron organizados. El historial local de IntelliJ recuperó perfectamente mis archivos no guardados, estoy muy agradecido por esta característica
Denes Papp
30
Simplemente lo hice git reset --hardy perdí todos mis cambios no comprometidos. Afortunadamente, uso un editor (IntelliJ) y pude recuperar los cambios del Historial local. Eclipse debería permitirle hacer lo mismo.
Por definición, git reset --hard descartará los cambios no confirmados sin que Git pueda recuperarlos (su sistema de respaldo puede ayudar, pero no Git).
En realidad, hay muy pocos casos en los que git reset --hardsea una buena idea. En la mayoría de los casos, hay un comando más seguro para hacer lo mismo:
Si desea descartar sus cambios no confirmados, úselos git stash. Mantendrá una copia de seguridad de estos cambios, que caducarán después de un tiempo si ejecuta git gc. Si está 99.9% seguro de que nunca necesitará estos cambios, git stashsigue siendo su amigo para el caso de 0.1%. Si está 100% seguro, git stashsigue siendo su amigo porque estos 100% tienen un error de medición ;-).
Si quieres mover tu HEADy la punta de la rama actual en la historia, entonces git reset --keepes tu amigo. Hará lo mismo que git reset --hard, pero no descartará sus cambios locales.
Si quieres hacer ambas cosas, entonces git stash && git reset --keepes tu amigo.
Enseñe a sus dedos a no usar git reset --hard, se pagará algún día.
entonces, si uno hace git stash && git reset --hardeso, eliminaría cualquier contenido escondido, ¿es así?
jxramos
1
No, git reset --hardno descarta el alijo. git stashes un reemplazo git reset --harden el sentido de que elimina los cambios no confirmados de su árbol de trabajo, excepto que los mantiene seguros en lugar de descartarlos permanentemente.
Matthieu Moy
o simplemente confirme sus cambios antes de restablecer el
hardware
11
si accidentalmente restablece una confirmación, entonces haga esto,
git reflog show
git reset HEAD@{2} // i.e where HEAD used to be two moves ago - may be different for your case
asumiendo que HEAD@{2}es el estado al que desea volver
esto funcionó perfecto para mí si haces esto en PowerShell, asegúrate de escribirlo como este git reset 'HEAD @ {2}' de lo contrario no funcionará en powershell
VectorX
10
Esto es lo que suelo hacer si pierdo algunos cambios.
git reflog
git checkout <commit id> // now you are in where you want but you cannot push from detached branch to master
manually copy and paste changes from detached branch to master or working branch
git reset --hard HEAD // if needed
git add ... > git commit ... > git push ...
para mover el puntero a sus confirmaciones anteriores pero manteniendo los cambios que ha realizado hasta ahora en su último pago de confirmaciones git reset --soft dadada
Como no se comprometió, su .git nunca almacenó esta información. Entonces, básicamente gitno puedo recuperarlo por ti.
Pero, si acabas de hacerlo git diff, hay una manera de recuperarte usando la salida del terminal con los siguientes 3 simples pasos.
desplaza tu terminal y busca la o / p de git diff. Guarde la o / p en un archivo llamado diff.patch
Busque y reemplace los 7 espacios y 8 espacios con caracteres de tabulación (\ t) y guarde los cambios.
Entra en tu repositorio de git. Aplicar el diff.patch ( patch -p1 < diff.patch)
Estás salvado! :)
Nota: Mientras esté copiando los datos del terminal a un archivo, tenga cuidado y vea claramente que los datos son de salida continua y no contienen datos redundantes (debido a presionar las flechas hacia arriba y hacia abajo). De lo contrario, podría estropearlo.
Me encontré con el mismo problema y casi me estaba volviendo loco ... inicialmente cometí el proyecto y me fusioné ... luego, cuando intento ejecutar, git push --set-upstream origin master recibí este error
fatal: refusing to merge unrelated histories
así que corrí git reset --hard HEADy eliminé un proyecto de 3 semanas, pero estos pocos comandos a continuación salvan el día:
git reset HEAD@{1} //this command unstage changes after reset
git fsck --lost-found //I got the dangling commit fc3b6bee2bca5d8a7e16b6adaca6a76e620eca4b
git show <dangling commit something like-> fc3b6bee2bca5d8a7e16b6adaca6a76e620eca4b>
git rebase fc3b6bee2bca5d8a7e16b6adaca6a76e620eca4b
Descubrí de la manera difícil que cualquier archivo no confirmado antes de ser git reset --hard <commit>eliminado del historial de git. Sin embargo, tuve la suerte de haber mantenido abierta mi sesión del editor de código durante todo el tiempo que me estaba arrancando el pelo, y descubrí que un simple control + zen cada uno de los archivos afectados devolvía el estado del archivo a la versión anterior a Git. restablecer amablemente todo lo que no le pedí específicamente.Hooray!!
Muchas gracias @mohammad, me salvó. No pude ver mis archivos fuente antes, pero siguiendo los pasos anteriores pude recuperar todos mis archivos fuente.
Gaurav Bansal
2
Respuestas correctas. OK, ahora me gusta git. :-) Aquí hay una receta más simple.
git log HEAD@{2}
git reset --hard HEAD@{2}
Donde "2" es el número de regreso a donde confirmó sus cambios. En mi caso, interrumpido por un colega y un jefe para ayudar a depurar algún problema de compilación; entonces, hizo un reinicio - duro dos veces; entonces, HEAD y HEAD @ {1} se sobrescribieron. Menos mal, habría perdido nuestro trabajo duro.
yo hice git reset --hard el proyecto equivocado por error (lo sé ...). Acababa de trabajar en un archivo y todavía estaba abierto durante y después de ejecutar el comando.
Aunque no me había comprometido, pude recuperar el archivo antiguo con el simple COMMAND + Z.
Si está desarrollando en Netbeans, mire entre las pestañas de archivos y el área de edición de archivos. Hay una "Fuente" e "Historia". En "Historial" verá los cambios realizados utilizando el control de versiones (git / other), pero también los cambios realizados localmente. En este caso, los cambios locales podrían salvarlo.
( respuesta adecuada para un subconjunto de usuarios )
Si está en macOS (cualquier reciente), e incluso si está lejos de su disco de Time Machine, el sistema operativo habrá guardado copias de seguridad por hora, llamadas
instantáneas locales .
Ingrese Time Machine y navegue hasta el archivo que perdió. El sistema operativo le preguntará:
The location to which you're restoring "file.ext" already contains an
item with the same name. Do you want to replace it with the one you're
restoring?
Si tenía un IDE abierto con el mismo código, intente hacer ctrl + z en cada archivo individual en el que haya realizado cambios. Me ayudó a recuperar mis cambios no comprometidos después de hacer git reset --hard.
Cuando hacemos git reset --hard y todos los cambios locales no confirmados se eliminan. Para recuperar los cambios: en IDE, haga clic en el archivo, compare el archivo con el historial local, que enumerará los cambios según la fecha y podremos recuperar los datos. ¡Tu día está salvado!
git reset
. No necesita ese comando y es peligroso, así que no lo use. Para devolver la rama a la confirmación anterior,git rebase -i
suelte las confirmaciones que no desea ogit checkout
(separa la cabeza) y luegogit branch -M
mueva la punta de la rama. El primero se negará a ejecutarse con cambios locales y el último solo se ejecutará si los archivos modificados localmente no difieren entre las revisiones.git reset --hard somewhere
es uno de los pocos comandos git realmente peligrosos.Respuestas:
No puede recuperar los cambios no confirmados en general.
Los cambios organizados previamente (
git add
) deben ser recuperables de los objetos de índice, por lo tanto, si lo hizo, usegit fsck --lost-found
para ubicar los objetos relacionados con él. (Esto escribe los objetos en el.git/lost-found/
directorio; desde allí puede usargit show <filename>
para ver el contenido de cada archivo).Si no, la respuesta aquí sería: mira tu copia de seguridad. Quizás su editor / IDE almacene copias temporales en / tmp o C: \ TEMP y cosas así. [1]
Esto restaurará a la CABEZA anterior
[1] vim, por ejemplo, opcionalmente almacena deshacer persistente, eclipse IDE almacena el historial local ; tales características podrían guardar su **
fuente
respuesta de este SO
¡Has recuperado tu día! :)
fuente
git checkout HEAD@{19}
me permitió revisar los archivos perdidos en un estado separado. Luego solíagit checkout -b new-branch-name
agregarlos nuevamente al repositorio en estado "adjunto".git checkout -b new-branch-name
. El libro Pragmatic Version Control Using Git es bueno para explicar Git en términos simples.Accidentalmente corrí
git reset --hard
en mi repositorio hoy también mientras tenía cambios sin confirmar también hoy. Para recuperarlo, ejecutégit fsck --lost-found
, que escribió todos los blobs sin referencia<path to repo>/.git/lost-found/
. Como los archivos no estaban confirmados, los encontré en elother
directorio dentro de<path to repo>/.git/lost-found/
. A partir de ahí, puedo ver los archivos no confirmados usandogit show <filename>
, copiar los blobs y cambiarles el nombre.Nota: Esto solo funciona si agregó los archivos que desea guardar en el índice (usando
git add .
). Si los archivos no estaban en el índice, se pierden.fuente
lost-found
. Pero entonces podría hacergit show
para obtener contenidos.#!/bin/bash cd PATH_TO_PROJECT/.git/lost-found/other FILES=* COUNTER = 0 for f in $FILES do echo "Processing $f file..." git show $f > "PATH_TO_RECOVERY_DIRECTORY/$COUNTER.m" let COUNTER=COUNTER+1 done
Sí, PUEDE RECUPERARSE de un restablecimiento completo en git.
Utilizar:
para obtener el identificador de su confirmación. Luego use:
Este truco me salvó la vida un par de veces.
Puede encontrar la documentación del reflog AQUÍ .
fuente
git reset --hard
uso de otro,git reset --hard
pero si no usa el--hard
interruptor, se le dejarán entradas en su espacio de trabajo que revertirán efectivamente el trabajo que acaba de recuperar.git log
, no vi la identificación de la confirmación. Congit reflog
pude ver la ID de confirmaciónMientras trabajaba en un proyecto local, quería moverlo a GitHub y luego crear un nuevo repositorio. Mientras intentaba agregar todos estos archivos al nuevo repositorio con .gitignore, accidentalmente agregué un archivo incorrecto y luego traté de borrarlo.
Corrí
git reset --hard origin/master
: PLuego, todos mis archivos locales se eliminaron porque el repositorio estaba vacío. Pensé que todo se había ido.
Esto me salvó la vida:
Espero que salve otra vida.
fuente
git reset HEAD@\{27\}
, ¡Gracias!git reflog show
para verificar y desde esa primera confirmación utilizogit reset HEAD@{number}
Si usa algo como IntelliJ:
En el menú contextual, elija Historial local y haga clic en Mostrar historial en el submenú:
http://blog.jetbrains.com/idea/2008/01/using-local-history-to-restore-deleted-files/
¡Esto acaba de sacar mi trasero del fuego!
fuente
git reflog
no funcionó porque no cometí los cambios.git fsck --lost-found
funcionó para archivos organizados pero no todos fueron organizados. El historial local de IntelliJ recuperó perfectamente mis archivos no guardados, estoy muy agradecido por esta característicaSimplemente lo hice
git reset --hard
y perdí todos mis cambios no comprometidos. Afortunadamente, uso un editor (IntelliJ) y pude recuperar los cambios del Historial local. Eclipse debería permitirle hacer lo mismo.fuente
Por definición,
git reset --hard
descartará los cambios no confirmados sin que Git pueda recuperarlos (su sistema de respaldo puede ayudar, pero no Git).En realidad, hay muy pocos casos en los que
git reset --hard
sea una buena idea. En la mayoría de los casos, hay un comando más seguro para hacer lo mismo:Si desea descartar sus cambios no confirmados, úselos
git stash
. Mantendrá una copia de seguridad de estos cambios, que caducarán después de un tiempo si ejecutagit gc
. Si está 99.9% seguro de que nunca necesitará estos cambios,git stash
sigue siendo su amigo para el caso de 0.1%. Si está 100% seguro,git stash
sigue siendo su amigo porque estos 100% tienen un error de medición ;-).Si quieres mover tu
HEAD
y la punta de la rama actual en la historia, entoncesgit reset --keep
es tu amigo. Hará lo mismo quegit reset --hard
, pero no descartará sus cambios locales.Si quieres hacer ambas cosas, entonces
git stash && git reset --keep
es tu amigo.Enseñe a sus dedos a no usar
git reset --hard
, se pagará algún día.fuente
git stash && git reset --hard
eso, eliminaría cualquier contenido escondido, ¿es así?git reset --hard
no descarta el alijo.git stash
es un reemplazogit reset --hard
en el sentido de que elimina los cambios no confirmados de su árbol de trabajo, excepto que los mantiene seguros en lugar de descartarlos permanentemente.si accidentalmente restablece una confirmación, entonces haga esto,
asumiendo que
HEAD@{2}
es el estado al que desea volverfuente
Esto es lo que suelo hacer si pierdo algunos cambios.
para mover el puntero a sus confirmaciones anteriores pero manteniendo los cambios que ha realizado hasta ahora en su último pago de confirmaciones
git reset --soft dadada
fuente
La información se pierde.
Como no se comprometió, su .git nunca almacenó esta información. Entonces, básicamente
git
no puedo recuperarlo por ti.Pero, si acabas de hacerlo
git diff
, hay una manera de recuperarte usando la salida del terminal con los siguientes 3 simples pasos.git diff
. Guarde la o / p en un archivo llamado diff.patchpatch -p1 < diff.patch
)Estás salvado! :)
Nota: Mientras esté copiando los datos del terminal a un archivo, tenga cuidado y vea claramente que los datos son de salida continua y no contienen datos redundantes (debido a presionar las flechas hacia arriba y hacia abajo). De lo contrario, podría estropearlo.
fuente
Me encontré con el mismo problema y casi me estaba volviendo loco ... inicialmente cometí el proyecto y me fusioné ... luego, cuando intento ejecutar,
git push --set-upstream origin master
recibí este errorasí que corrí
git reset --hard HEAD
y eliminé un proyecto de 3 semanas, pero estos pocos comandos a continuación salvan el día:espero que esto ayude
fuente
Puede recuperar una confirmación después de hacer un
reset --hard HEAD
.Utilice "
git reflog
" para verificar el historial deHEAD
la rama.Verá su commit y su id aquí.
Hacer un
fuente
Si por suerte tuvo los mismos archivos abiertos en otro editor (p. Ej., Sublime Text) intente ctrl-z en esos. Simplemente me salvó ..
fuente
Descubrí de la manera difícil que cualquier archivo no confirmado antes de ser
git reset --hard <commit>
eliminado del historial de git. Sin embargo, tuve la suerte de haber mantenido abierta mi sesión del editor de código durante todo el tiempo que me estaba arrancando el pelo, y descubrí que un simplecontrol + z
en cada uno de los archivos afectados devolvía el estado del archivo a la versión anterior a Git. restablecer amablemente todo lo que no le pedí específicamente.Hooray!!
fuente
Si está intentando usar el siguiente código:
y por alguna razón están obteniendo:
luego intenta envolver
HEAD@{1}
entre comillasfuente
4 es cambios antes de hace 4 pasos. si selecciona un paso correcto, debería mostrar la lista de archivos que eliminó del disco duro. entonces hazlo:
le mostrará el historial de confirmación local que ya hemos creado. ahora haz:
8c4d112 es un código que desea restablecer su disco duro allí. echemos un vistazo a https://www.theserverside.com/video/How-to-use-the-git-reset-hard-command-to-change-a-commit-history para obtener más información.
fuente
Respuestas correctas. OK, ahora me gusta git. :-) Aquí hay una receta más simple.
Donde "2" es el número de regreso a donde confirmó sus cambios. En mi caso, interrumpido por un colega y un jefe para ayudar a depurar algún problema de compilación; entonces, hizo un reinicio - duro dos veces; entonces, HEAD y HEAD @ {1} se sobrescribieron. Menos mal, habría perdido nuestro trabajo duro.
fuente
yo hice
git reset --hard
el proyecto equivocado por error (lo sé ...). Acababa de trabajar en un archivo y todavía estaba abierto durante y después de ejecutar el comando.Aunque no me había comprometido, pude recuperar el archivo antiguo con el simple
COMMAND + Z
.fuente
Respuesta de referencia de este SO,
Después de ejecutar git reflog show, di que quieres ir a commit 9300f9d
después de ejecutar git reset 9300f9d
puede hacer el estado de git, y luego es posible que deba retirar sus archivos para restaurar sus cambios
git checkout - ruta de archivo / nombre
fuente
Si está desarrollando en Netbeans, mire entre las pestañas de archivos y el área de edición de archivos. Hay una "Fuente" e "Historia". En "Historial" verá los cambios realizados utilizando el control de versiones (git / other), pero también los cambios realizados localmente. En este caso, los cambios locales podrían salvarlo.
fuente
( respuesta adecuada para un subconjunto de usuarios )
Si está en macOS (cualquier reciente), e incluso si está lejos de su disco de Time Machine, el sistema operativo habrá guardado copias de seguridad por hora, llamadas instantáneas locales .
Ingrese Time Machine y navegue hasta el archivo que perdió. El sistema operativo le preguntará:
Debería poder recuperar los archivos que perdió.
fuente
Si tenía un IDE abierto con el mismo código, intente hacer ctrl + z en cada archivo individual en el que haya realizado cambios. Me ayudó a recuperar mis cambios no comprometidos después de hacer git reset --hard.
fuente
Cuando hacemos git reset --hard y todos los cambios locales no confirmados se eliminan. Para recuperar los cambios: en IDE, haga clic en el archivo, compare el archivo con el historial local, que enumerará los cambios según la fecha y podremos recuperar los datos. ¡Tu día está salvado!
fuente