Recherche…


Remarques

Le reflog de Git enregistre la position de HEAD (la référence de l'état actuel du référentiel) chaque fois qu'il est modifié. Généralement, chaque opération qui pourrait être destructive implique de déplacer le pointeur HEAD (car si quelque chose est modifié, y compris dans le passé, le hachage de la commande tip change), il est toujours possible de revenir à un état antérieur à une opération dangereuse , en trouvant la bonne ligne dans le reflog.

Les objets qui ne sont référencés par aucune référence sont généralement récupérés en 30 jours environ, de sorte que le renvoi peut ne pas toujours être utile.

Se remettre d'une mauvaise rebase

Supposons que vous ayez démarré un rebase interactif:

git rebase --interactive HEAD~20

et par erreur, vous avez écrasé ou laissé tomber des commits que vous ne vouliez pas perdre, mais vous avez ensuite terminé le rebase. Pour récupérer, faites git reflog , et vous pourriez voir des résultats comme ceci:

aaaaaaa HEAD@{0} rebase -i (finish): returning to refs/head/master
bbbbbbb HEAD@{1} rebase -i (squash): Fix parse error
...
ccccccc HEAD@{n} rebase -i (start): checkout HEAD~20
ddddddd HEAD@{n+1} ...
...

Dans ce cas, le dernier commit, ddddddd (ou HEAD@{n+1} ) est la pointe de votre branche de pré-rebase . Ainsi, pour récupérer ce commit (et tous les commits parents, y compris ceux écrasés ou supprimés accidentellement), faites:

$ git checkout HEAD@{n+1}

Vous pouvez ensuite créer une nouvelle branche à cette validation avec git checkout -b [branch] . Voir Branchement pour plus d'informations.



Modified text is an extract of the original Stack Overflow Documentation
Sous licence CC BY-SA 3.0
Non affilié à Stack Overflow