L’Outil Surpuissant pour Exploser ton Chiffre d'Affaires en 2025 !
Un guide pour annuler les erreurs avec Git
Travailler avec du code est une entreprise risquée: il existe d'innombrables façons de se tirer une balle dans le pied! Mais si vous utilisez Git comme système de contrôle de version, vous disposez d'un excellent filet de sécurité. De nombreux outils «d'annulation» vous aideront à vous remettre de presque n'importe quel type de catastrophe.
Dans ce premier article de notre série en deux parties, nous examinerons diverses erreurs – et comment les annuler en toute sécurité avec Git!
] Ignorer les modifications non validées dans un fichier
Supposons que vous ayez apporté des modifications à un fichier et que, après un certain temps, vous remarquez que vos efforts ne mènent nulle part. Il serait préférable de recommencer et d’annuler les modifications apportées à ce fichier.
La bonne nouvelle est que si vous n’avez pas validé les modifications, il est assez facile de les annuler. Mais il y a aussi une mauvaise nouvelle: vous ne pouvez pas ramener les modifications une fois que vous les avez annulées! Comme ils n'ont pas été enregistrés dans la «base de données» de Git, il n'y a aucun moyen de les restaurer!
Avec ce petit avertissement à l'écart, annulons nos modifications dans index.html :
$ git restore index.html
Cette commande restaurera notre fichier à son dernier état de validation, en l’effacant de toute modification locale.
Restauration d’un fichier supprimé
Prenons l’exemple précédent un peu plus loin. Disons qu'au lieu de modifier index.html vous l'avez entièrement supprimé . Encore une fois, supposons que vous ne l'ayez pas encore validé dans le référentiel.
Vous serez heureux d'apprendre que git restore est équipé pour gérer cette situation tout aussi facilement:
$ git restore index.html
La commande restore ne se soucie pas vraiment de ce que exactement vous avez fait à ce pauvre fichier. Il recrée simplement son dernier état engagé!
Annuler certaines de vos modifications
La plupart des jours sont un mélange de bon et de mauvais travail. Et parfois, nous avons les deux dans un seul fichier: certaines de vos modifications seront excellentes (soyons généreux et appelons-les génie), tandis que d'autres sont adaptées à la poubelle.
Git vous permet de travailler avec des changements de manière très granulaire chemin. L'utilisation de git restore avec l'indicateur -p rend toute cette opération d'annulation beaucoup plus nuancée:
$ git restore -p index.html
Git nous prend par la main et nous guide à travers chaque morceau de changements dans le fichier, en demandant si nous voulons le jeter (dans ce cas, nous taperions y ) ou conservez-le (en tapant n ):
Si vous utilisez un utilisateur de bureau Git interface, vous pouvez aller encore plus loin. Des applications comme celles-ci vous permettent de sélectionner le code à conserver, supprimer et mettre en scène non seulement au niveau des blocs, mais même pour lignes de code individuelles . L'un de ces outils est Tower celui sur lequel le vôtre travaille vraiment.
Correction du tout dernier commit
Levez la main si vous n'avez jamais fait de faute de frappe dans un message de commit ou si vous n'avez jamais oublié d'ajouter une dernière modification. Pas de mains? C'est ce que je pensais. Parce que gâcher un commit est si terriblement courant, Git rend très facile la correction de telles erreurs.
Regardons un excellent exemple d'un mauvais message de commit:
L'utilisation de l'option - modifier vous permet de modifier ce tout dernier commit (et uniquement celui-ci):
$ git commit --amend -m "Un message sans fautes de frappe"
Au cas où vous auriez également oublié d'ajouter une certaine modification vous pouvez facilement le faire. Mettez-le simplement en scène comme n'importe quel autre changement avec la commande git add puis exécutez à nouveau git commit --amend :
$ git add lost-change.txt
$ git commit --amend --no-edit
L'option - no-edit indique à Git que nous ne voulons pas changer le message du commit cette fois.
Revert the Effects of a Bad Commit
Dans tout ce qui précède cas, nous avons été assez rapides pour reconnaître nos erreurs. Mais souvent, nous n’apprendrons qu’une erreur longtemps après l’avoir commise. Le mauvais commit se trouve dans notre historique de révision, nous scrutant sournoisement.
Bien sûr, il existe également une solution à ce problème: la commande git revert ! Et cela résout notre problème de manière très non destructive. Au lieu d'extraire notre mauvais commit de l'historique, il crée un nouveau commit qui contient les changements opposés.
Faire cela sur la ligne de commande est aussi simple que de fournir le hachage de révision de ce mauvais commit à la commande git revert :
$ git revert 2b504bee
Comme mentionné, cela ne supprimera pas notre mauvais commit (ce qui pourrait être problématique si nous l'avons déjà partagé avec des collègues dans un référentiel distant). Au lieu de cela, un nouveau commit contenant les modifications annulées sera automatiquement créé.
Restaurer un état antérieur du projet
Parfois, nous devons admettre que nous nous sommes codés dans une impasse. Peut-être que nos deux derniers commits n'ont donné aucun fruit et sont mieux défaits.
Heureusement, ce problème est assez facile à résoudre. Nous devons simplement fournir le hachage SHA-1 de la révision à laquelle nous voulons revenir lorsque nous utilisons la commande git reset . Tous les commits postérieurs à cette révision disparaîtront alors:
$ git reset --hard 2b504bee
L'option - hard garantit qu'il nous reste une copie de travail propre . Alternativement, nous pouvons utiliser l'option - mixed pour un peu plus de flexibilité (et de sécurité): - mixed conservera les modifications contenues dans les commits supprimés en tant que modifications locales dans notre copie de travail.
Récupérer les commits perdus à l'aide de Reflog
À présent, vous avez probablement remarqué que, lorsqu'il s'agit d'annuler des erreurs, presque tout est possible avec Git! Cela comprend l'annulation d'une annulation . Disons que nous avons réalisé que la git reset que nous venons d’effectuer ci-dessus n’était pas notre idée la plus brillante. Nous craignons d’avoir perdu de précieux engagements, ce qui nous a mis en mode panique.
Comme vous pouvez le deviner maintenant, nous pouvons également résoudre ce problème à l’aide d’un outil particulier. reflog est une sorte de journal dans lequel Git enregistre tous les mouvements du pointeur HEAD . En d'autres termes, à chaque fois que nous commettons, récupérons, fusionnons, rebasons, sélectionnons à la cerise, etc., une nouvelle entrée sera créée dans ce journal. Heureusement, cela se produit également lorsque nous utilisons git reset !
Ouvrons reflog avec une simple commande de git reflog . Jetez un œil à ce que nous avons:
La première chose à savoir sur le reflog est qu'il est ordonné par ordre chronologique . Par conséquent, il n'est pas surprenant de voir notre récente erreur git reset tout en haut. Si nous voulons maintenant annuler cela, nous pouvons simplement revenir à l'état d'avant, qui est également protocole ici, juste en dessous!
Nous pouvons maintenant copier le hachage de validation de cet état sûr et créer une nouvelle branche basée sur celui-ci: [19659011] $ git branch happy-end e5b19e4
Bien sûr, nous aurions pu aussi utiliser git reset e5b19e4 pour revenir à cet état. Personnellement, cependant, je préfère créer une nouvelle branche: elle ne présente aucun inconvénient et me permet de vérifier si cet état est vraiment ce que je veux.
Restaurer un fichier unique à partir d'un état précédent
Jusqu'à présent, quand nous 'ai travaillé avec des états engagés, nous avons toujours travaillé avec le projet complet. Mais que se passe-t-il si nous voulons restaurer un seul fichier pas tout le projet? Par exemple, disons que nous avons supprimé un fichier, pour découvrir bien plus tard que nous n'aurions pas dû. Pour nous sortir de cette misère, nous devrons résoudre deux problèmes:
- trouver le commit où nous avons supprimé le fichier,
- puis (et seulement alors) le restaurer.
Allons chercher l'historique des commit pour notre pauvre fichier perdu:
$ git log -
La sortie de ceci liste tous les commits où ce fichier a été modifié. Et comme la sortie de log est triée par ordre chronologique, nous ne devrions pas avoir à rechercher longtemps – le commit dans lequel nous avons supprimé le fichier sera probablement le plus élevé (car après l'avoir supprimé, le fichier ne s'affichera probablement pas
Avec le hachage de ce commit et le nom de notre fichier, nous avons tout ce dont nous avons besoin pour le ramener d'entre les morts:
$ git checkout ~ 1 -
Notez que nous utilisons ~ 1 pour traiter le commit avant celui où nous avons effectué la suppression. Cela est nécessaire car le commit où la suppression a eu lieu ne contient plus le fichier, nous ne pouvons donc pas l'utiliser pour restaurer le fichier.
Vous êtes maintenant (presque) invincible
Au cours de cet article, nous avons été témoins de nombreux désastres – mais nous avons vu que pratiquement rien n'est irréparable dans Git! Une fois que vous connaissez les bonnes commandes, vous pouvez toujours trouver un moyen de sauver votre cou.
Mais pour vraiment devenir invincible (dans Git, c'est-à-dire), vous devrez attendre la deuxième partie de cette série . Nous examinerons d'autres problèmes épineux, tels que comment récupérer des branches supprimées, comment déplacer des commits entre des branches et comment combiner plusieurs commits en un seul!
En attendant, si vous voulez en savoir plus sur l'annulation des erreurs avec Git, je recommande le " First Aid Kit for Git " gratuit, une série de courtes vidéos sur ce même sujet.
A bientôt dans la deuxième partie de cette série! Abonnez-vous à la Smashing Newsletter pour ne pas manquer celle-là. ; -)
(vf, il, al) Source link