Annuler, défaire, corriger

Dans le quotidien d’un·e développeu·r·se, les erreurs sont inévitables. Que ce soit un message de commit mal formulé, un fichier oublié ou un changement incorrect, il est crucial de savoir rectifier le tir. Git offre plusieurs moyens de “défaire” ou de corriger des erreurs. Dans cette section, nous allons explorer les différentes procédures à mettre en œuvre selon le contexte.

Pourquoi défaire est essentiel ?

Défaire, c’est bien plus que revenir en arrière. C’est garantir que l’historique de notre projet reste clair et compréhensible. Lorsque des erreurs subsistent dans les commits, elles peuvent rendre le développement collaboratif plus difficile, introduire des bugs ou compliquer la maintenance. Savoir corriger proprement ces erreurs permet de maintenir un historique propre et de collaborer efficacement avec notre équipe.

Quelles situations ?

Listons ici les principales situations auxquelles on peut être confronté :

1. je veux annuler un commit, le retirer de l’historique (sans garder ce qu’il contient) ;
2. j’ai commité trop vite, je veux l’annuler et continuer à modifier ce qu’il contenait ;
3. j’ai oublié d’ajouter un fichier ou des modifications dans un commit ;
4. j’ai fait un commit fourre-tout, je veux le défaire et refaire un commit par sujet ;
5. j’ai ajouté des modifications ou fichiers en trop à un commit ;
6. je veux défaire un commit “temporaire” (alors que j’aurais dû utiliser le stash) ;
7. j’ai mal rédigé le message d’un commit ;
8. je m’y suis pris à plusieurs fois/commits pour résoudre un problème (plusieurs commits au lieu d’un) ;
9. j’ai créé un commit sur la mauvaise branche ;
10. mon rebase était une mauvaise idée, je souhaite l’annuler ;
11. ma fusion (merge) était une mauvaise idée, je souhaite l’annuler ;
12. je veux annuler le pull que je viens de faire.

NB : Je ne parle volontairement pas ici des situations avant commit. Celles-ci s’annulent via la commande restore qui est assez triviale et la marche à suivre est toujours décrite par la commande git status.

Est-ce toujours possible ?

La réponse courte est : « Oui ! Git permet de tout faire ! ».

Sauf qu’on doit parfois arbitrer avant de nous lancer dans cette démarche de correction ou d’annulation car, selon le contexte, le jeu n’en vaut pas la chandelle, surtout lorsqu’on est nombreu·x·ses à travailler sur le projet.

Est-ce que je peux changer un historique déjà partagé ?

Là encore, la réponse est « oui » ! Git n’émet aucune contrainte. Il nous incombe donc de choisir les situations où on s’autorise cette pratique qui demandera de forcer le push. Attention toutefois à le faire convenablement.

Évidemment, pour les annulations, il faudra les faire quoi qu’il en soit, mais la solution choisie peut varier.

Comment juger alors ?

Ça n’est pas toujours évident, mais il est de bon aloi de définir certaines “règles” et “conventions” pour faciliter ces choix. Ça touche alors à ce qu’on appelle communément les worfkows.

Si on est l’unique personnes à travailler sur un projet, le contexte est favorable à toute modification car personne ne souffrira de transformation de l’historique partagé. On s’autorise généralement à écraser l’historique de n’importe quelle branche.

Dans un contexte de collaboration, on préfére plutôt “verrouiller” certaines branches critiques (branche de production et pré-production par exemple). On autorise la modification des branches en bout de chaîne. Le verrouillage en question peut être couplé par une gestion de droit fine côté serveur Git. Par exemple, sur GitHub, on peut interdire tout envoi direct sur certaines branches au profit d’une intégration par pull request.

Voici donc quelques recommandations :

1. On évite de remanier le tronc commun car ça nécessite d’écraser l’historique partagé et de remettre à jour toutes les sous-branches. Çaa demande aussi une synchronisation complexe des équipes travaillant sur le projet.
2. Si possible on verrouille ces branches en définissant sur les serveurs des droits appropriés.
3. Pour annuler un ajout au tronc commun, on préférera utiliser un revert, notamment pour une raison de suivi (attention dans ce cas à intégrer via une fusion en mode squash).
4. On essaye de mesurer les bénéfices/inconvénients : si le remaniement prend plus de quelques minutes, il faut qu’il soit critique au projet. Sinon, on laissera en l’état ou préférera l’ajout de commits pour corriger.

Plusieurs commandes

Pour les exemples cités, plusieurs commandes vont nous servir à défaire et corriger : restore, reset, revert et rebase. Ne t’inquiète pas pour ce point ni pour la complexité que tu pourrais trouver aux solutions présentées car, même si tu ne maitrise pas parfaitement ces commandes, tu pourras reprendre nos articles comme guides pratiques “pas à pas”.

Tu n’as plus qu’à parcourir les différents articles pour apprendre à résoudre les différents scenarios !.