Existe-t-il un moyen de récupérer les modifications non validées du répertoire de travail à partir d'un git reset --hard HEAD
?
git reset --hard somewhere
c'est l'une des rares commandes git vraiment dangereuses.
Existe-t-il un moyen de récupérer les modifications non validées du répertoire de travail à partir d'un git reset --hard HEAD
?
git reset --hard somewhere
c'est l'une des rares commandes git vraiment dangereuses.
Réponses:
Vous ne pouvez pas récupérer les modifications non validées en général.
Les modifications précédemment mises en scène ( git add
) devraient être récupérables à partir des objets d'index, donc si vous l'avez fait, utilisez git fsck --lost-found
pour localiser les objets qui y sont liés. (Cela écrit les objets dans le .git/lost-found/
répertoire; à partir de là, vous pouvez utiliser git show <filename>
pour voir le contenu de chaque fichier.)
Sinon, la réponse serait: regardez votre sauvegarde. Peut-être que votre éditeur / IDE stocke les copies temporaires sous / tmp ou C: \ TEMP et des choses comme ça. [1]
git reset HEAD@{1}
Cela restaurera à la tête précédente
[1] vim, par exemple, stocke éventuellement une annulation persistante, l' IDE éclipse stocke l'historique local ; de telles fonctionnalités pourraient vous faire économiser un **
réponse de ce SO
$ 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}
Vous avez récupéré votre journée! :)
git checkout HEAD@{19}
m'a permis de vérifier les fichiers perdus dans un état détaché. Puis utilisé git checkout -b new-branch-name
pour les ajouter au dépôt dans l'état "attaché".
git checkout -b new-branch-name
. Le livre Pragmatic Version Control Using Git est bon pour expliquer Git en termes simples.
J'ai accidentellement exécuté git reset --hard
mon repo aujourd'hui aussi tout en ayant des changements non engagés aujourd'hui. Pour le récupérer, j'ai couru git fsck --lost-found
, qui a écrit tous les blobs non référencés dans <path to repo>/.git/lost-found/
. Comme les fichiers n'étaient pas validés, je les ai trouvés dans le other
répertoire du <path to repo>/.git/lost-found/
. De là, je peux voir les fichiers non validés en utilisant git show <filename>
, copier les blobs et les renommer.
Remarque: cela ne fonctionne que si vous avez ajouté les fichiers que vous souhaitez enregistrer dans l'index (à l'aide git add .
). Si les fichiers n'étaient pas dans l'index, ils sont perdus.
lost-found
. Mais je pourrais alors faire git show
pour obtenir le contenu.
#!/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
Oui, vous pouvez récupérer à partir d'une réinitialisation matérielle dans git.
Utilisation:
git reflog
pour obtenir l'identifiant de votre commit. Utilisez ensuite:
git reset --hard <commit-id-retrieved-using-reflog>
Cette astuce m'a sauvé la vie plusieurs fois.
Vous pouvez trouver la documentation de reflog ICI .
git reset --hard
utilisant un autre, git reset --hard
mais si vous n'utilisez pas le --hard
commutateur, vous vous retrouverez avec des entrées dans votre espace de travail qui annuleraient efficacement le travail que vous venez de récupérer.
git log
je n'ai pas vu l'id du commit. Avec git reflog
je pouvais voir l'ID de validation
Pendant que je travaillais sur un projet local, je voulais le déplacer vers GitHub puis créer un nouveau référentiel. Pendant que j'essayais d'ajouter tous ces fichiers au nouveau référentiel avec .gitignore, j'ai accidentellement ajouté un mauvais fichier, puis j'ai essayé de le supprimer.
J'ai couru git reset --hard origin/master
: P
Ensuite, tous mes fichiers locaux ont été supprimés car le dépôt était vide. Je pensais que tout était parti.
Cela m'a sauvé la vie:
git reflog show
git reset HEAD@{1}
git push
J'espère que cela sauve une autre vie.
git reset HEAD@\{27\}
, merci!
git reflog show
pour vérifier et à partir de ce premier commit j'utilisegit reset HEAD@{number}
Si vous utilisez quelque chose comme IntelliJ:
Dans le menu contextuel, choisissez Historique local, puis cliquez sur Afficher l'historique dans le sous-menu:
La vue historique locale d'un projet ou d'un dossier vous montre tout ce que vous avez fait au cours des derniers jours. Dans la colonne Action de la partie inférieure de la boîte de dialogue, sélectionnez l'action que vous souhaitez annuler. [...] Ce faisant, la partie supérieure de la boîte de dialogue affiche l'arborescence des fichiers modifiés. Si vous souhaitez restaurer uniquement le fichier supprimé, quelles que soient les autres modifications apportées depuis, vous pouvez sélectionner le fichier Lost.txt dans l'arborescence et cliquer sur le bouton Rétablir.
http://blog.jetbrains.com/idea/2008/01/using-local-history-to-restore-deleted-files/
Cela vient de sortir mon cul du feu!
git reflog
n'a pas fonctionné car je n'ai pas validé les modifications. git fsck --lost-found
travaillé pour les fichiers intermédiaires mais pas tous. L'historique local d'IntelliJ a parfaitement récupéré mes fichiers non enregistrés, je suis tellement reconnaissant pour cette fonctionnalité
Je viens de le faire git reset --hard
et j'ai perdu tous mes changements non engagés. Heureusement, j'utilise un éditeur (IntelliJ) et j'ai pu récupérer les modifications de l'historique local. Eclipse devrait vous permettre de faire de même.
Par définition, git reset --hard
supprimera les modifications non validées sans aucun moyen pour Git de les récupérer (votre système de sauvegarde peut aider, mais pas Git).
En fait, il y a très peu de cas où git reset --hard
c'est une bonne idée. Dans la plupart des cas, il existe une commande plus sûre pour faire la même chose:
Si vous souhaitez supprimer vos modifications non validées, utilisez git stash
. Il conservera une sauvegarde de ces modifications, qui expirera après un certain temps si vous exécutez git gc
. Si vous êtes sûr à 99,9% que vous n'aurez plus jamais besoin de ces modifications, git stash
votre ami sera toujours le cas à 0,1%. Si vous êtes sûr à 100%, git stash
c'est toujours votre ami car ces 100% ont une erreur de mesure ;-).
Si vous voulez déplacer votre HEAD
et la pointe de la branche actuelle dans l'histoire, alors git reset --keep
c'est votre ami. Il fera la même chose que git reset --hard
, mais ne rejettera pas vos modifications locales.
Si vous voulez faire les deux, alors git stash && git reset --keep
c'est votre ami.
Apprenez à vos doigts à ne pas l'utiliser git reset --hard
, cela vous remboursera un jour.
git stash && git reset --hard
cela effacer tout contenu caché est-ce pas?
git reset --hard
ne jette pas la cachette. git stash
est un remplacement git reset --hard
dans le sens où il supprime les modifications non validées de votre arbre de travail, sauf qu'il les garde en sécurité au lieu de les supprimer définitivement.
si vous réinitialisez accidentellement un commit, faites-le,
git reflog show
git reset HEAD@{2} // i.e where HEAD used to be two moves ago - may be different for your case
en supposant que HEAD@{2}
vous souhaitez revenir à l'état
C'est ce que je fais habituellement si je perds certains changements.
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 ...
pour ramener le pointeur sur vos validations précédentes, mais en conservant les modifications que vous avez apportées jusqu'à présent lors de votre dernière validation des validations git reset --soft dadada
L'information est perdue.
Puisque vous ne vous êtes pas engagé, votre .git n'a jamais stocké ces informations. Donc, fondamentalement, git
je ne peux pas le récupérer pour vous.
Mais, si vous venez de le faire git diff
, il existe un moyen de récupérer en utilisant la sortie du terminal avec les 3 étapes simples suivantes.
git diff
. Enregistrez l'o / p dans un fichier appelé diff.patchpatch -p1 < diff.patch
)Vous êtes sauvé! :)
Remarque: Pendant que vous copiez les données du terminal vers un fichier, soyez prudent et voyez clairement que les données sont une sortie continue et ne contiennent aucune donnée redondante (en raison de l'appui sur les flèches haut et bas). Sinon, vous pourriez tout gâcher.
J'ai rencontré le même problème et j'étais presque devenu fou ... au début, j'ai commis le projet et j'ai fusionné ... plus tard, lorsque j'essaie de courir, git push --set-upstream origin master
j'obtenais cette erreur
fatal: refusing to merge unrelated histories
j'ai donc couru git reset --hard HEAD
et il a supprimé un projet de 3 semaines mais ces quelques commandes ci-dessous sauvent la mise:
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
J'espère que cela t'aides
Vous pouvez récupérer un commit après avoir fait un reset --hard HEAD
.
Utilisez " git reflog
" pour vérifier l'historique de HEAD
la branche.
Vous verrez votre commit et son id ici.
Fait une
git reset {commit Id of the commit you want to bring back}
J'ai découvert à la dure que tous les fichiers non validés avant d' git reset --hard <commit>
être supprimés de l'historique git. Cependant, j'ai eu la chance d'avoir gardé ma session d'éditeur de code ouverte pendant tout le temps que je me suis arraché les cheveux, que j'ai découvert qu'un simple control + z
dans chacun des fichiers affectés renvoyait l'état du fichier à la version avant Git, donc réinitialiser obligatoirement tout ce que je ne lui ai pas demandé spécifiquement.Hooray!!
git reset HEAD@{4}
4 est des changements avant il y a 4 étapes. si vous sélectionnez une étape correcte, elle devrait afficher la liste des fichiers que vous avez supprimés du disque dur. alors fais:
$ git reflog show
il va vous montrer l'historique des validations locales que nous avons déjà créées. maintenant:
$ git reset --hard 8c4d112
8c4d112 est un code que vous souhaitez réinitialiser votre disque dur. regardons https://www.theserverside.com/video/How-to-use-the-git-reset-hard-command-to-change-a-commit-history pour obtenir plus d'informations.
Réponses correctes. OK, maintenant j'aime git. :-) Voici une recette plus simple.
git log HEAD@{2}
git reset --hard HEAD@{2}
Où "2" est le nombre de retour à l'endroit où vous avez validé vos modifications. Dans mon cas, interrompu par un collègue et un patron pour aider à déboguer un problème de build; donc, a fait un reset --hard deux fois; donc, HEAD et HEAD @ {1} ont été écrasés. Ouf, aurait perdu un notre de dur labeur.
J'ai fait git reset --hard
le mauvais projet par erreur (je sais ...). Je venais de travailler sur un fichier et il était toujours ouvert pendant et après avoir exécuté la commande.
Même si je ne m'étais pas engagé, j'ai pu récupérer l'ancien fichier avec le simple COMMAND + Z
.
Réponse de référence de cet OS,
Après avoir exécuté git reflog show, dites que vous voulez valider 9300f9d
après avoir exécuté git reset 9300f9d
vous pouvez faire le statut git, puis vous devrez peut-être extraire votre fichier (s) pour restaurer vos modifications
git checkout - chemin / fichier
Si vous développez sur Netbeans, regardez entre les onglets de fichiers et la zone d'édition de fichiers. Il y a une "Source" et une "Histoire". Sur "Historique", vous verrez les modifications effectuées à l'aide du contrôle de version (git / other), mais également les modifications apportées localement. Dans ce cas, des modifications locales pourraient vous sauver.
( réponse adaptée à un sous-ensemble d'utilisateurs )
Si vous êtes sur (tout récent) macOS, et même si vous êtes loin de votre disque Time Machine, le système d'exploitation aura enregistré des sauvegardes horaires, appelées instantanés locaux .
Entrez dans Time Machine et accédez au fichier que vous avez perdu. L'OS vous demandera alors:
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?
Vous devriez pouvoir récupérer le ou les fichiers que vous avez perdus.
Si vous aviez un IDE ouvert avec le même code, essayez de faire un ctrl + z sur chaque fichier individuel auquel vous avez apporté des modifications. Cela m'a aidé à récupérer mes modifications non validées après avoir effectué la réinitialisation de git --hard.
Lorsque nous git reset --hard et toutes les modifications locales non validées sont supprimées. Pour récupérer les modifications - dans IDE, cliquez sur le fichier, comparez le fichier avec l'historique local qui répertorie les modifications par date et nous pouvons récupérer les données. Votre journée est sauvée!
git reset
. Vous n'avez pas besoin de cette commande et c'est dangereux, alors ne l'utilisez pas. Pour ramener la branche au commit précédentgit rebase -i
, supprimez les commits que vous ne voulez pas ougit checkout
(détache la tête), puisgit branch -M
déplacez la pointe de la branche. Le premier refusera de s'exécuter avec les modifications locales et le second ne fonctionnera que si les fichiers modifiés localement ne diffèrent pas entre les révisions.