5 façons d'annuler les erreurs avec Git

Quelle que soit votre expérience, l'art du développement de logiciels ne peut pas être pratiqué sans commettre d'erreurs. Mais ce qui sépare la moyenne des grands programmeurs, c'est qu'ils savent commentannulerleurs erreurs !

Si vous utilisez Git comme système de contrôle de version, vous disposez déjà d'une multitude d'"outils d'annulation" à portée de main. Cet article vous montrera cinq façons puissantes deannuler les erreurs avec Git!

Ignorer certaines de vos modifications locales

Le codage est souvent un processus compliqué. Parfois, on a l'impression de faire deux pas en avant et un pas en arrière. En d'autres termes : une partie du code que vous avez produit est excellente… mais une partie moins. C'est là que Git peut vous aider : il vous permet de conserver ce qui est bon et d'annuler les changements dont vous ne voulez plus.

Jetons un coup d'œil à un exemple de scénario avec quelques modifications "locales" (c'est-à-dire des modifications que nous n'avons pas encore validées).

Remarque : pour une meilleure vue d'ensemble et une visualisation plus claire, j'utilise leClient de bureau Tower Git dans certaines de mes captures d'écran. Vous n'avez pas besoin de Tower pour suivre ce didacticiel.

Abordons le problème dansgeneral.css première. Les changements que nous avons apportés sont allés dans une direction totalement erronée. Annulons-les tous et recréons le dernier état validé de ce fichier :

$gitrestaurer css/general.css

Notez que, alternativement, j'aurais pu utiliser lepaiement git commande pour obtenir le même résultat. Mais parce quepaiement gita tellement d'emplois et de significations différentes, je préfère fortement le légèrement plus récentrestauration gitcommande (qui se concentre uniquement sur ces types de tâches).

Notre deuxième problème enindex.html est un peu plus délicat. Certaines des modifications que nous avons apportées à ce fichier sont en fait excellentes, alors que seules certaines d'entre elles doivent être annulées.

De nouveau,restauration gitvient à la rescousse – mais cette fois avec le-pflag, car on veut descendre au niveau « patch » :

$gitrestaurer -p index.html

Git vous prendra alors par la main et vous demandera —pour chaque morceau de changementsdans ce fichier – si vous voulez le supprimer ou non.

Vous remarquerez que j'ai tapé « n » pour le premier bloc (afin de le conserver) et « y » pour le deuxième bloc (afin de le supprimer). Une fois le processus terminé, vous pouvez voir que seule la première partie précieuse des modifications a survécu, comme nous le souhaitions !

Réinitialisation d'un fichier spécifique à un état précédent

Parfois, vous souhaiterez restaurer unspécifiquefichier àspécifique révision. Par exemple, vous savez queindex.html fonctionnait bien à un moment donné, mais maintenant ce n'est plus le cas. C'est alors que vous souhaitez remonter le temps, mais uniquement pour ce fichier spécifique et non pour l'ensemble du projet !

La première chose que nous devons savoir est quelle révision exacte nous voulons restaurer. Avec le bon ensemble de paramètres, vous pouvez obtenir lejournal gitcommande pour vous montrer l'historique de notre seul fichier :

$gitjournal -- index.html

Cela nous montre seulement les commits oùindex.htmla été modifié, ce qui est très utile pour trouver la révision de la "pomme pourrie" qui a cassé les choses.

Si vous avez besoin de plus d'informations et que vous souhaitez consulterContenude ces commits, vous pourriez demander à Git de vous montrer les changements réels dans ces commits avec le-pdrapeau:

$gitlog -p -- index.html

Une fois que nous avons trouvé le mauvais commit où nous avons cassé notre joli petit fichier, nous pouvons continuer et corriger l'erreur. Nous le ferons en restaurant le fichier lors de la révisionavant que le mauvais ! C'est important : nous ne voulons pas restaurer le fichier au commit qui a introduit l'erreur, mais au dernier bon état — un commit avant ça !

$gitvérifier<bad-commit-hash>~1 -- index.html

Ajout~1au hachage du mauvais commit demandera à Git de faire exactement cela : faire une révisionavant quecelui référencé.

Après avoir exécuté cette commande, vous trouverezindex.htmlà modifier dans votre copie de travail locale : Git a restauré cette dernière bonne révision du fichier pour nous !

Récupérer une révision perdue avec le Reflog

Un autre excellent outil d'annulation dans la trousse de secours de Git est le "Reflog". Vous pouvez le considérer comme un journal dans lequel Git enregistre tous les mouvements du pointeur HEAD qui se produisent dans votre référentiel local – des choses comme les validations, les extractions, les fusions et les rebases, les sélections et les réinitialisations. Toutes les actions les plus intéressantes sont bien enregistrées ici !

Un tel journal, bien sûr, est parfait pour les occasions où les choses tournent mal. Commençons donc par provoquer une petite catastrophe — que nous pourrons ensuite réparer avec le Reflog.

Disons que vous étiez convaincu que vos derniers commits n'étaient pas bons : vous vouliez vous en débarrasser et donc utiliséréinitialisation de git pour revenir à une révision précédente. En conséquence, les "mauvais" commits ont disparu de votre historique de commit – comme vous le vouliez.

Mais comme la vie se passe parfois, on s'aperçoit que c'était une mauvaise idée : au final, les commits n'étaient pas si mal après tout ! Mais la mauvaise nouvelle, bien sûr, c'est que vous venez de les effacer de l'historique des commits de votre dépôt ! 😱

C'est un cas classique pour l'outil Reflog de Git ! Voyons comment cela peut sauver votre cou :

$gitreflog

Décomposons cela petit à petit :

• Tout d'abord, le Reflog est très facile à ouvrir : un simplegit reflogest tout ce dont vous avez besoin.
• Deuxièmement, vous remarquerez que les états enregistrés sont triés par ordre chronologique, avec le plus récent en haut.
• Si vous regardez attentivement, vous verrez que l'élément le plus élevé (c'est-à-dire le plus récent) est une action de « réinitialisation ». C'est ce que nous venons de faire il y a 20 secondes. Apparemment, le journal fonctionne 😉
• Si nous voulons maintenant annuler notre "réinitialisation" involontaire, nous pouvons simplement revenir à l'état précédent – ce qui est également parfaitement documenté ici ! Nous pouvons simplement copier le hachage de validation de cet état précédent dans le presse-papiers et le reprendre à partir de là.

Pour restaurer cet état précédent, nous pouvons soit utiliserréinitialisation de gità nouveau ou créez simplement une nouvelle branche :

$gitbranche happy end e5b19e4

Comme nous pouvons le vérifier avec plaisir, notre nouvelle branche contient les commits que nous pensions avoir perdus à cause de notre erreur accidentelle.réinitialisation de githoquet!

Récupérer une branche supprimée

Le Reflog peut également être utile dans d'autres situations. Par exemple, lorsque vous avez supprimé par inadvertance une branche que vous ne devriez vraiment (!) pas avoir. Jetons un coup d'œil à notre exemple de scénario :

$gitbranche * maître de fonctionnalité/analytique

Imaginons que notre client / chef d'équipe / chef de projet nous dise que la belleanalytique fonctionnalité sur laquelle nous avons travaillé n'est plus souhaitée. Bien rangés comme nous sommes, nous supprimons le correspondantfonctionnalité/analysebranche, bien sûr !

Ci-dessus, vous pouvez voir que, dans notre exemple de scénario, cette branche est actuellement extraite :fonctionnalité/analyse est notre branche HEAD actuelle. Pour pouvoir le supprimer, nous devons d'abord passer à une autre branche :

$gitmaître de caisse $gitbranch -d feature/analytics error : La branche'fonctionnalité/analytique' n'est pas entièrement fusionné.  Si vous êtes sûr de vouloir le supprimer, exécutez'git branch -D feature/analytics'.

Git nous dit que nous sommes sur le point de faire quelque chose de vraiment sérieux : puisquefonctionnalité/analyse contient des commits uniques qui ne sont présents nulle part ailleurs, sa suppression détruira certaines données (potentiellement précieuses). Eh bien… puisque la fonctionnalité n'est plus nécessaire, nous pouvons continuer :

$gitbranch -D feature/analytics Fonctionnalité/analytics de branche supprimée(était b1c249b).

Vous avez probablement déjà anticipé ce qui s'en vient maintenant : notre client/chef d'équipe/chef de projet nous annonce avec joie que la fonctionnalité est de retour dans le jeu ! 🥳 Ils veulent le poursuivre après tout ! 🎉

Encore une fois, nous sommes confrontés à une situation laide où nous pourrions avoir perdu des données précieuses ! Voyons donc si le Reflog peut nous sauver la tête une fois de plus :

$gitreflog

La bonne nouvelle devient évidente si vous y regardez de plus près. Avant de pouvoir (catastrophiquement) supprimer notre branche, nous avons dû effectuer unepaiement git pour s'en éloigner (puisque Git ne vous permet pas de supprimer la branche actuelle). Bien sûr, celavérifier a également été enregistré dans le Reflog. Afin de restaurer notre branche supprimée, nous pouvons maintenant simplement prendre l'étatavant quecomme point de départ pour une nouvelle branche :

$gitfonction de branche/analyse b1c249b

Et voilà : notre branche est revenue d'entre les morts ! 🌸💀🌺

Si vous utilisez une interface graphique de bureau commeLa tourannuler des erreurs comme celles-ci est souvent aussi simple que d'appuyer surCMD+DEPUIS.

Déplacer un commit vers une autre branche

Terminons avec un autre vrai classique du « Oh non ! département : commettre sur la mauvaise branche.

Aujourd'hui, de nombreuses équipes ont mis en place une règle qui interdit de s'engager directement dans des branches de longue durée telles que "main", "master" ou "develop". En règle générale, les nouveaux commits ne devraient arriver sur ces branches que par le biais de fusions/rebases. Et pourtant, on oublie parfois et on s'engage directement…

Prenons le scénario suivant comme exemple.

Nous aurions dû nous engager surreportage/bulletinmais a appuyé par inadvertance sur la gâchette duMaître une succursale. Regardons la solution, étape par étape.

Tout d'abord, nous devons nous assurer que nous sommes sur la bonne branche cette fois-ci, nous vérifions doncreportage/bulletin:

$gitfonctionnalité de paiement/newsletter

Maintenant, nous pouvons déplacer ce commit en toute sécurité en utilisant lecueillette de cerisescommande:

$gitcueillette de cerises 26bf1b48

Nous pouvons jeter un oeil àreportage/bulletinet verrons que, maintenant, le commit existe ici aussi.

Jusqu'ici tout va bien. Maiscueillette de cerisesn'a paséliminerle commit de laMaîtrebranche – où il devraitjamais a été. Nous devrons donc également nettoyer notre gâchis là-bas:

$gitmaître de caisse $gitréinitialiser --hard HEAD~1

Nous revenons àMaîtrepuis en utilisantréinitialisation de gitpour supprimer le commit indésirable (ici) de l'historique.

Enfin, tout va bien à nouveau – vous pouvez donc commencer votre danse joyeuse maintenant ! 💃🕺🏻

Défaire les erreurs est un super pouvoir

Je l'ai déjà dit, et malheureusement nous savons tous que c'est vrai : nous ne pouvons pas éviter les erreurs ! Peu importe à quel point nous sommes un bon programmeur, nous nous tromperons de temps en temps. La question n'est donc passinous faisons des erreurs, mais plutôtdans quelle mesure pouvons-nous les gérer et résoudre les problèmes ?

Si vous voulez en savoir plus sur les outils d'annulation de Git, je vous recommande fortement le "Trousse de premiers soins pour Git ”. Il s'agit d'une collection (gratuite) de courtes vidéos qui vous montrent comment nettoyer et annuler les erreurs dans Git.

Amusez-vous à vous déplacer rapidement, à casser des choses – et bien sûr, à les réparer !