Polarys
Git et versioning : les bases/Réparer ses erreurs

Réparer ses erreurs

Annuler sans casser l'historique

La peur qui bloque les débutants

Ce qui fait hésiter devant Git n'est pas la difficulté des commandes, c'est la crainte de détruire quelque chose sans pouvoir revenir en arrière.

Bonne nouvelle, et elle change tout : presque rien n'est perdu dans Git une fois que c'est commité. Ce qui est réellement fragile, ce sont les modifications non commitées. C'est là qu'il faut être prudent, et nulle part ailleurs.

Quatre situations, quatre commandes

SituationCommandeDétruit du travail ?
Fichier modifié, à jetergit restore fichieroui, définitivement
Fichier ajouté par erreur au staginggit restore --staged fichiernon
Dernier commit à refairegit commit --amendnon, si non poussé
Commit à annuler alors qu'il est pousségit revert <hash>non

La première ligne est la seule vraiment dangereuse de tout ce tableau. Un git restore sur un fichier modifié écrase votre travail sans confirmation et sans récupération possible : ce contenu n'a jamais existé pour Git.

Corriger le dernier commit

Un message mal écrit, un fichier oublié :

git add fichier-oublie.yml
git commit --amend -m "Message corrigé"

À faire uniquement si le commit n'est pas encore poussé. Amender réécrit le commit : s'il est déjà chez les autres, leur historique et le vôtre divergent, et la suite est pénible pour tout le monde.

Annuler un commit déjà poussé

git revert 3f2a1b9

revert crée un nouveau commit qui défait les modifications du commit visé. L'historique n'est pas réécrit : la trace de l'erreur et celle de sa correction restent visibles.

C'est le comportement souhaitable sur une branche partagée, et c'est aussi ce que Polarys inscrit dans le champ revert de chacun de ses tickets : une commande prête à coller, décidée au moment où l'on comprend encore ce que le changement faisait.

Le filet de sécurité que personne ne connaît

git reflog

Le reflog garde la trace de chaque position de votre branche pendant plusieurs semaines, y compris ce qui n'apparaît plus dans l'historique. Un commit perdu après une manipulation malheureuse se retrouve presque toujours ici.

C'est la première chose à taper quand vous croyez avoir tout perdu, avant de recommencer votre travail.

Mettre de côté sans commiter

git stash                 # met les modifications de côté
git stash pop             # les récupère

Utile quand une urgence tombe au milieu d'un travail en cours. Mais un stash oublié est un travail perdu de fait : rien ne vous le rappellera. Préférez un commit sur une branche de travail, quitte à ce que le message soit provisoire.

À retenir

Ce qui est commité se récupère, y compris via le reflog. Ce qui ne l'est pas se perd. Amendez tant que ce n'est pas poussé, faites un revert dès que ça l'est, et commitez plutôt que de remiser.

Quiz de validation

Quiz - 3 questions

1. Quelle opération détruit réellement du travail sans récupération possible ?

2. Un commit fautif est déjà poussé sur la branche partagée. Que faire ?

3. Que taper en premier quand un commit semble avoir disparu ?

Suis ta progression

Crée un compte gratuit pour suivre ta progression et accéder à toutes les leçons.