Cet article fait partie de la série "Advanced Git". Assurez-vous de nous suivre sur Twitter ou de vous inscrire à notre newsletter pour voir les futurs articles!
La fonctionnalité "Reflog" de Git est peu connue, mais c'est très pratique. Certaines personnes l'appellent un "filet de sécurité" et je préfère le considérer comme un "journal" de Git. En effet Git enregistre vos actions dans Reflog, ce qui en fait un journal de bord précieux et un bon point de départ lorsque des problèmes surviennent.
Dans la dernière partie de cette série "Advanced Git", je vais expliquer la différence entre git log
et git reflog
et vous montrer comment utiliser Reflog pour récupérer les engagements supprimés et les branches supprimées.
git log
ou git reflog
: Quelle est la différence? Dans les articles précédents, j'ai suggéré d'utiliser la commande git log
pour vérifier les événements précédents et afficher votre historique de validation, ce qu'il fait exactement. Il affiche la tête actuelle et ses ancêtres, c'est-à-dire son parent, le prochain parent, etc. Les journaux remontent jusqu'au début de l'histoire des engagements en imprimant récursivement le parent de chaque engagement. Il fait partie du référentiel, ce qui signifie qu'il sera copié après avoir poussé, récupéré ou tiré.
D'un autre côté, git reflog
est un enregistrement lié à l'espace de travail privé. Il n'imagine pas la liste des ancêtres. Au lieu de cela, il affiche une liste ordonnée de tous les validations pointées par la tête dans le passé. C'est pourquoi vous pouvez le considérer comme une sorte d '"annul d'histoire" comme vous le voyez dans les traitements de texte, les éditeurs de texte, etc.
Ce dossier local ne fait pas techniquement partie du référentiel et il est stocké séparément de l'engagement. Reflog est un fichier dans .git/logs/refs/heads/
qui suit les commits locaux de chaque branche. Les journaux de Git sont généralement nettoyés après 90 jours (c'est la valeur par défaut), mais vous pouvez facilement ajuster la date d'expiration du réflog. Pour changer le nombre de jours à 180, tapez simplement la commande suivante:
$ git config gc.reflogexpire 180.days.ago
Alternativement, vous pouvez décider que votre réflog n'expirera jamais:
$ git config gc.reflogexpire jamais
Astuce: N'oubliez pas que GIT distingue les fichiers de configuration du référentiel ( .git/config
), la configuration mondiale de l'utilisateur ( $HOME/.gitconfig
) et les paramètres à l'échelle du système ( /etc/gitconfig
). Pour ajuster la date d'expiration du réflug de l'utilisateur ou du système, ajoutez --system
ou --global
à la commande ci-dessus.
Assez un arrière-plan théorique - permettez-moi de vous montrer comment utiliser git reflog
pour corriger les erreurs.
Imaginez le scénario suivant: après avoir visionné l'histoire de la validation, vous décidez de supprimer les deux derniers engagements. Vous avez courageusement exécuté git reset
, et les deux commits ont disparu de l'histoire de la validation ... après un certain temps, vous avez remarqué qu'il s'agissait d'un bug. Vous venez de perdre vos précieux changements et avez commencé à paniquer!
Devez-vous vraiment partir de zéro? Pas besoin. En d'autres termes: restez calme et utilisez git reflog
!
Alors gâchons les choses et faisons cette erreur dans la vraie vie. L'image suivante montre notre histoire de validation originale dans Tower (un client Git graphique):
Nous voulons supprimer les deux commits et définir le changement et imprimer le titre de titre (ID: 2B504BEE) comme dernière révision de notre branche principale. Nous copie simplement l'ID de hachage dans le presse-papiers, puis utilisons git reset
dans la ligne de commande et entrez cette valeur de hachage:
$ git réinitialisation - dure 2B504BEE
Regarder! La soumission a disparu. Maintenant, supposons que ce soit une erreur et examinons le réflog pour récupérer les données perdues. Tapez git reflog
pour voir le journal dans votre terminal:
Vous remarquerez que toutes les entrées sont organisées par ordre chronologique. Cela signifie: le dernier commit est au sommet. Et, si vous regardez attentivement, vous remarquerez l'opération git reset
mortelle en haut il y a quelques minutes.
Le journal semble fonctionner - c'est une bonne nouvelle. Alors utilisons-le pour annuler la dernière action et restaurer l'état avant la commande de réinitialisation. Comme avant, copiez l'ID de hash (E5B19E4 dans cet exemple particulier) dans le presse-papiers. Vous pouvez utiliser à nouveau git reset
, ce qui fonctionne parfaitement. Mais dans ce cas, je vais créer une nouvelle branche basée sur l'ancien état:
$ Git Branch Happy-Find E5B19E4
Jetons un coup d'œil à notre client Git Git à nouveau:
Comme vous pouvez le voir, une nouvelle succursale appelée Happy-Encente a été créée avec nos commits précédemment supprimés - génial, rien n'est perdu!
Regardons un autre exemple et utilisons le réflog pour restaurer toute la branche.
L'exemple suivant est similaire à notre premier scénario: nous supprimerons quelque chose - cette fois toute la branche. Peut-être que votre client ou chef d'équipe vous dit de supprimer une branche de fonctionnalités, c'est peut-être l'idée de nettoyer vous-même. Pire, un engagement (C3 sur l'image) n'est inclus dans aucune autre branche, donc vous perdez définitivement des données:
Faisons cela et restaurons ensuite la branche plus tard:
Vous devez le laisser avant de supprimer feature/login
. (Comme indiqué dans la capture d'écran, c'est la branche de tête actuelle, vous ne pouvez pas supprimer la branche de la tête en git.) Nous allons donc changer la branche (à maître), puis nous supprimerons feature/login
:
Ok… maintenant supposons que notre client ou notre chef d'équipe a changé d'avis. Après tout, des branches feature/login
(y compris leurs commits) sont nécessaires. Que devons-nous faire?
Jetons un œil au journal de Git:
$ git réflog 776F8CA (tête -> Master) Head @ {0}: Checkout: Déplacement de la fonctionnalité / connexion à Master B1C249B (fonctionnalité / connexion) tête @ {1}: Checkout: Passer du maître en fonctionnalité / connexion [...]
Nous nous sommes avérés à nouveau chanceux. La dernière entrée montre comment nous passons de feature/login
à Master. Essayons de revenir à l'état précédent et de copier l'ID de hachage B1C249B dans le presse-papiers. Ensuite, nous créerons une succursale nommée feature/login
en fonction de l'état requis:
$ Git Branch Feature / Connexion B1C249B $ Git Branch -vv fonctionnalité / connexion b1c249b modifier le titre de la page iprint * Master 776F8CA Modifier sur le titre et la page d'erreur de suppression
Génial - La branche récupère de la mort et comprend également des commits précieux que nous considérons comme perdus:
Si vous utilisez Git dans une GUI de bureau comme une tour, vous pouvez annuler votre dernière action simplement en appuyant sur CMD Z comme un éditeur de texte ou un traitement de texte lorsque vous tapez une erreur.
Le réflog de Git peut être un vrai Sauveur! Comme vous pouvez le voir, il est très facile de retirer les commits manquants de la tombe ou même de toute la branche. Tout ce que vous avez à faire est de trouver la bonne pièce d'identité de hachage dans le reflug - le reste est un morceau de gâteau.
Si vous souhaitez creuser des outils Git avancés, n'hésitez pas à consulter ma boîte à outils Git (gratuite!): Il s'agit d'une collection de courtes vidéos sur des sujets tels que des stratégies de branchement, des rébases interactives, des reflugs, des sous-modules, et plus encore.
Ceci est la dernière partie de notre série "Advanced Git" sur CSS-Tricks. J'espère que vous avez apprécié ces articles. Joyeux hacker!
Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!