Quelle est la différence entre git reflog et log ?

Question

La page de manuel dit que log montre les journaux de commit et reflog gère les informations reflog. Que sont exactement les informations reflog et qu'ont-elles de plus que le journal ? Le journal semble beaucoup plus détaillé.

Answer 1

git log montre l'HEAD actuel et son ascendance. C'est-à-dire qu'il affiche le commit vers lequel HEAD pointe, puis son parent, son parent, et ainsi de suite. Il parcourt l'ascendance du repo, en recherchant récursivement le parent de chaque commit.

(En pratique, certains commits ont plus d'un parent. Pour voir un journal plus représentatif, utilisez une commande comme git log --oneline --graph --decorate .)

git reflog ne traverse pas du tout l'ascendance de HEAD. Le reflog est une liste ordonnée des commits vers lesquels HEAD a pointé : c'est l'historique des annulations pour votre dépôt. Le reflog ne fait pas partie du repo lui-même (il est stocké séparément des commits eux-mêmes) et n'est pas inclus dans les pushes, fetches ou clones ; il est purement local.

A propos : comprendre le reflog signifie que vous ne pouvez pas vraiment perdre les données de votre repo une fois qu'il a été committé. Si vous réinitialisez accidentellement un commit plus ancien, ou rebasez mal, ou toute autre opération qui "supprime" visuellement des commits, vous pouvez utiliser le reflog pour voir où vous en étiez auparavant et git reset --hard revenir à cette référence pour rétablir votre état antérieur. N'oubliez pas que les références n'impliquent pas seulement le commit mais aussi toute l'histoire qui le sous-tend.

Answer 2

• git log montre le journal de commit accessible depuis les refs (têtes, tags, remotes)
• git reflog est un record de tous les commits qui sont ou ont été référencés dans votre repo à tout moment.

C'est pourquoi git reflog (a local qui est élagué après 90 jours par défaut) est utilisé lorsque vous effectuez une opération "destructive" (comme la suppression d'une branche), afin de récupérer le SHA1 qui était référencé par cette branche.
Voir git config :

gc.reflogexpire
gc.<pattern>.reflogexpire

git reflog expire supprime les entrées reflog plus anciennes que ce délai ; la valeur par défaut est de 90 jours.
Avec " <pattern> "(par exemple, " refs/stash ") au milieu, le réglage ne s'applique qu'aux arbitres qui correspondent à l'image de l'arbitre. <pattern> .

git reflog est souvent référencé comme " votre filet de sécurité "

En cas de problème, le conseil général, lorsque le journal git ne vous montre pas ce que vous cherchez, est le suivant :

" Restez calme et utilisez git reflog "

Encore une fois, reflog est un enregistrement local de votre SHA1.
Par opposition à git log : si vous poussez votre repo vers un repo amont vous verrez la même chose git log mais pas nécessairement les mêmes git reflog .

Answer 3

Voici le l'explication de reflog du livre Pro Git :

L'une des choses que Git fait en arrière-plan pendant que vous travaillez est de tenir un reflog - un journal de l'emplacement de vos références HEAD et branches au cours des derniers mois.

Vous pouvez voir votre reflog en utilisant git reflog :

$ git reflog
734713b... HEAD@{0}: commit: fixed refs handling, added gc auto, updated
d921970... HEAD@{1}: merge phedders/rdocs: Merge made by recursive.
1c002dd... HEAD@{2}: commit: added some blame and merge stuff
1c36188... HEAD@{3}: rebase -i (squash): updating HEAD
95df984... HEAD@{4}: commit: # This is a combination of two commits.
1c36188... HEAD@{5}: rebase -i (squash): updating HEAD
7e05da5... HEAD@{6}: rebase -i (pick): updating HEAD

Chaque fois que l'extrémité de votre branche est mise à jour pour une raison quelconque, Git stocke cette information pour vous dans cet historique temporaire. Et vous pouvez également spécifier des commits plus anciens avec ces données.

El reflog La commande peut également être utilisée pour supprimer les entrées ou expirer les entrées du reflog qui sont trop anciennes. À partir de l'écran la documentation officielle Git du noyau Linux pour reflog :

La sous-commande expire est utilisé pour élaguer les anciennes entrées de reflog.

Pour supprimer des entrées individuelles du journal de bord, utilisez la sous-commande delete et spécifier l'entrée exacte (par ex. git reflog delete master@{2} ).

Answer 4

J'étais également curieux de savoir ce qu'il en était et je voudrais juste développer et résumer un peu :

1. git log affiche un historique de tous vos commits pour la branche sur laquelle vous vous trouvez. Vérifiez une autre branche et vous verrez un historique différent. Si vous voulez voir l'historique de vos commits pour toutes les branches, tapez git log --all .

2. git reflog montre un enregistrement de vos références comme l'a dit Cupcake. Il y a une entrée à chaque fois qu'un commit ou un checkout est effectué. Essayez d'aller et venir entre deux branches plusieurs fois en utilisant git checkout et exécuter git reflog après chaque passage en caisse. Vous verrez que l'entrée supérieure est mise à jour à chaque fois en tant qu'entrée "caisse". Vous ne voyez pas ces types d'entrées dans git log .

Références : http://www.lornajane.net/posts/2014/git-log-all-branches

Answer 5

J'aime à penser que la différence entre git log et reflog est la différence entre un dossier privé et un dossier public.

Privé ou public

Avec le reflog de git, il garde la trace de tout ce que vous avez fait localement. Avez-vous fait un commit ? Reflog le suit. Avez-vous fait un hard reset ? Reflog le suit. Avez-vous modifier un engagement ? Reflog le suit. Tout ce que vous avez fait localement, il y a une entrée pour cela dans le reflog.

Ce n'est pas le cas pour le journal. Si vous modifiez un commit, le journal ne montre que le nouveau commit. Si vous faites une réinitialisation et revenez quelques commits en arrière dans votre historique, ces commits que vous avez sauté n'apparaîtront pas dans le journal. Quand vous poussez vos changements vers un autre développeur ou vers GitHub ou quelque chose comme ça, seul le contenu suivi dans le journal apparaîtra. Pour un autre développeur, c'est comme si les réinitialisations ou les modifications n'avaient jamais eu lieu.

La bûche est polie. Le reblog est lapidaire.

Alors oui, j'aime l'analogie entre le privé et le public. Ou peut-être une meilleure log et reflog L'analogie est "poli contre lapidaire". Le reflog montre tous vos essais et erreurs. Le journal ne montre qu'une version propre et polie de votre histoire professionnelle.

Jetez un coup d'œil à cette image pour souligner le point. Un certain nombre de modifications et de réinitialisations ont eu lieu depuis que le référentiel a été initialisé. Le reflog montre tout cela. Pourtant, la commande log donne l'impression qu'il n'y a eu qu'un seul commit sur le dépôt :

Retour à l'idée du "filet de sécurité".

De plus, puisque le reflog garde la trace des choses que vous avez modifiées et des commits que vous réinitialiser il vous permet de revenir en arrière et de trouver ces commits parce qu'il vous donnera les identifiants des commits. En supposant que votre référentiel n'a pas été purgé des anciens commits, cela vous permet de ressusciter des éléments qui ne sont plus visibles dans le journal. C'est ainsi que le reflog finit parfois par sauver la peau de quelqu'un qui a besoin de récupérer quelque chose qu'il pensait avoir perdu par inadvertance.