Un guide pour annuler les erreurs avec Git (partie 2)

Dans cette deuxième partie de notre série sur «Annuler les erreurs avec Git», nous allons bravement regarder à nouveau le danger dans les yeux: I 'ai préparé quatre nouveaux scénarios apocalyptiques – y compris, bien sûr, des moyens intelligents de sauver nos cous! Mais avant de plonger: jetez un œil aux articles précédents sur Git pour encore plus de méthodes d'auto-sauvetage qui vous aideront à réparer vos erreurs avec Git!

Allons-y!

Récupération d'un Branche supprimée à l'aide de Reflog

Avez-vous déjà supprimé une branche et, peu de temps après, réalisé que vous n'auriez pas dû? Dans le cas peu probable où vous ne connaissez pas ce sentiment, je peux vous dire que ce n’est pas un bon sentiment. Un mélange de tristesse et de colère vous envahit, pendant que vous pensez à tout le travail acharné qui a été consacré aux commits de cette branche, à tout le code précieux que vous avez maintenant perdu.

Heureusement, il existe un moyen de ramener cette branche from the dead – avec l'aide d'un outil Git nommé «Reflog». Nous avions utilisé cet outil dans la première partie de notre série mais voici un petit rappel: le Reflog est comme un journal où Git note chaque mouvement du pointeur HEAD dans votre référentiel local. En d'autres termes, moins ringards: à chaque fois que vous effectuez une vérification, une validation, une fusion, un rebase, une sélection cerise, etc., une entrée de journal est créée. Cela fait du Reflog un filet de sécurité parfait en cas de problème!

Prenons un exemple concret:

 $ git branch
* fonctionnalité / connexion
Maître

Nous pouvons voir que notre branche fonctionnalité / login est actuellement vérifiée. Disons que c'est la branche que nous allons supprimer (par inadvertance). Avant de pouvoir faire cela, cependant, nous devons changer de branche car nous ne pouvons pas supprimer notre branche HEAD actuelle!

 $ git checkout master
$ git branch -d fonctionnalité / connexion

Notre précieuse branche de fonctionnalités a maintenant disparu – et je vais vous donner une minute pour (a) comprendre la gravité de notre erreur et (b) pleurer un peu. Après avoir essuyé les larmes, nous devons trouver un moyen de ramener cette branche! Ouvrons le Reflog (simplement en tapant git reflog ) et voyons ce qu'il nous réserve:

Voici quelques commentaires pour vous aider à donner un sens à la sortie:

• Tout d'abord, vous devez savoir que Reflog trie ses entrées par ordre chronologique: les éléments les plus récents sont à
• L'élément le plus haut (et donc le plus récent) est la commande git checkout que nous avons exécutée avant de supprimer la branche. Il est enregistré ici dans le Reflog parce que c'est l'un de ces «mouvements du pointeur HEAD» que le Reflog enregistre si consciencieusement.
• Pour réparer notre grave erreur, nous pouvons simplement revenir à l'état d'avant ce – qui est

Essayons donc ceci, en créant une nouvelle branche (avec le nom de notre branche "perdue") qui commence à cet état "avant" de hachage SHA-1:

 $ fonctionnalité de branche git / login 776f8ca

Et voilà! Vous serez ravi de voir que nous avons maintenant restauré notre branche apparemment perdue! 🎉

Si vous utilisez une interface graphique de bureau Git comme "Tower" vous pouvez prendre un raccourci intéressant: appuyez simplement sur CMD + Z sur votre clavier pour annuler la dernière commande – même si vous venez de supprimer violemment une branche!

Déplacement d'un commit vers une branche différente

Dans beaucoup équipes, il y a un accord pour ne pas s'engager sur des branches de longue durée comme main ou develop : les branches comme celles-ci ne devraient recevoir de nouveaux commits que par le biais d'intégrations (par ex. rebase). Et pourtant, bien sûr, les erreurs sont inévitables: on oublie parfois et on s'engage sur ces branches quand même! Alors, comment pouvons-nous nettoyer le gâchis que nous avons fait?

Heureusement, ces types de problèmes peuvent être facilement corrigés. Retroussons nos manches et allons au travail.

La première étape consiste à passer à la bonne branche de destination, puis à déplacer le commit en utilisant la commande cherry-pick :

 $ git checkout feature / connexion
$ git cherry-pick 776f8caf

Vous aurez maintenant le commit sur la branche désirée, là où il aurait dû être en premier lieu. Génial!

Mais il reste une chose à faire: nous devons nettoyer la succursale où elle accidentellement a atterri au début! La commande cherry-pick pour ainsi dire, a créé une copie du commit – mais l'original est toujours présent sur notre branche de longue date:

Cela signifie que nous devons revenir à notre branche de longue date et utiliser git reset pour le supprimer:

 $ git checkout main
$ git reset --hard HEAD ~ 1

Comme vous pouvez le voir, nous utilisons ici la commande git reset pour effacer le commit défectueux. Le paramètre HEAD ~ 1 dit à Git de «remonter 1 révision derrière HEAD», effaçant effectivement le commit le plus élevé (et dans notre cas: indésirable) de l'historique de cette branche.

Et voilà: le commit est maintenant là où il aurait dû être en premier lieu et notre branche de longue date est propre – comme si notre erreur ne s'était jamais produite!

Modification du message d'un ancien commit

C'est tout trop facile de faire passer une faute de frappe dans un message de validation – et de ne le découvrir que beaucoup plus tard. Dans un tel cas, la bonne vieille option - amend de git commit ne peut pas être utilisée pour résoudre ce problème, car elle ne fonctionne que pour le tout dernier commit. Pour corriger tout commit plus ancien, nous devons recourir à un outil Git appelé "Interactive Rebase".

Tout d'abord, nous devons indiquer à Interactive Rebase la partie de l'historique des commit que nous voulons éditer. Ceci est fait en lui donnant un hachage de commit: le commit parent de celui que nous voulons manipuler.

 $ git rebase -i 6bcf266b

Une fenêtre d'édition s'ouvrira alors. Il contient une liste de tous les commits après celui que nous avons fourni comme base pour la Rebase interactive dans la commande:

Ici, il est important que vous ne ne suivez pas votre première impulsion: dans cette étape, nous ne modifions pas le message de validation , encore. Au lieu de cela, nous disons seulement à Git quel type de manipulation nous voulons faire avec quel (s) commit (s). Pour plus de commodité, une liste de mots clés d’action est indiquée dans les commentaires au bas de cette fenêtre. Dans notre cas, nous marquons la ligne n ° 1 avec reformulation (remplaçant ainsi le choix standard ).

Il ne reste plus qu'à enregistrer et fermer l'éditeur la fenêtre. En retour, une nouvelle fenêtre d'édition s'ouvrira contenant le message actuel du commit que nous avons balisé. Et maintenant est enfin le moment de faire nos modifications!

Voici tout le processus en un coup d'œil pour vous: