Jusqu'à présent on a considéré le scénario idéal : vous écrivez du code, faites des commits, créez un Pull Request. Mais dans la vraie vie, souvent quelque chose se passe mal : vous pouvez faire une erreur dans le code, faire un commit avec un message incorrect ou simplement comprendre que vous n'allez pas dans la bonne direction. Dans cette leçon on va voir comment résoudre les problèmes les plus courants.
1. Rollback — annuler les modifications avant le commit
Scénario : vous avez modifié un fichier, mais vous réalisez que toutes vos modifications sont incorrectes et vous voulez rapidement remettre le fichier dans l'état où il était après le dernier commit.
Utilisez la fonction Rollback :
- Ouvrez l'onglet
Commit. - Trouvez dans la liste le fichier modifié que vous voulez "rollback".
- Cliquez dessus avec le bouton droit et choisissez
Rollback.
L'IDE vous avertira que les changements seront perdus. Acceptez, et le fichier reviendra instantanément à sa dernière version sauvegardée dans Git. C'est le moyen le plus simple et le plus sûr d'annuler des modifications locales.
2. Reset — suppression des commits locaux
Scénario : vous avez fait un ou plusieurs commits, mais vous n'avez pas encore fait de push. Vous avez compris que ces commits sont erronés et vous voulez les supprimer complètement, comme s'ils n'avaient jamais existé.
Utilisez la fonction Reset :
- Ouvrez l'onglet
Git -> Logpour voir l'historique des commits. - Trouvez le dernier "bon" commit où vous voulez revenir (celui qui était avant les commits erronés).
- Cliquez dessus avec le bouton droit et choisissez
Reset Current Branch to Here....
Dans la fenêtre qui s'ouvre on vous proposera de choisir le mode de reset. Le plus radical est Hard.
Attention ! Le mode Hard supprime de façon irréversible tous les commits après celui choisi, ainsi que toutes les modifications de code contenues dans ces commits. Utilisez-le avec beaucoup de prudence et seulement pour des commits que personne n'a encore vus (ceux qui n'ont pas été envoyés sur GitHub).
3. Que faire après le Push ?
Scénario : vous avez fait un push, et seulement après vous avez remarqué une erreur dedans.
Dès que le commit est arrivé sur le serveur distant, il devient partie intégrante de l'historique commun du projet. Tenter de réécrire cet historique peut créer d'énormes problèmes pour vos collègues. Imaginez qu'ils ont déjà récupéré vos changements et commencé à travailler dessus.
Solution correcte et sûre :
Faites simplement un nouveau commit qui corrige l'erreur, et poussez-le. C'est une pratique tout à fait normale. De cette façon, l'historique reste honnête et compréhensible pour tout le monde.
4. Regarder dans le passé : travail avancé avec le log
Nous connaissons déjà l'onglet Git -> Log, mais ce n'est pas seulement une liste de commits, c'est un outil puissant pour les investigations.
- Hash du commit (Commit Hash) : vous avez sûrement remarqué dans le log une chaîne de lettres et de chiffres, par exemple
a1b2c3d. Ce hash est unique, il permet de référencer précisément n'importe quel point dans l'historique du projet. Vous aurez rarement besoin de l'utiliser manuellement, mais il est important de savoir que c'est l'identifiant unique de chaque "snapshot" de votre code.![]()
- Vous pouvez filtrer l'historique par branche, auteur, date ou même par mot dans le message du commit. Cela aide à trouver rapidement qui et quand a travaillé sur une partie donnée du code.
- Vous voulez trouver le commit où une ligne spécifique de code a été ajoutée ou supprimée ? Dans la fenêtre
Logil y a un champ de recherche qui cherche non seulement dans les messages mais aussi dans le contenu des changements. - Cliquez avec le bouton droit dans les marges de l'éditeur de code et choisissez
Annotate with Git Blame. L'IDE montrera à côté de chaque ligne qui et dans quel commit l'a modifiée pour la dernière fois. C'est incroyablement utile pour comprendre pourquoi le code est écrit de cette façon.
5. Zone dangereuse : Force Push
Donc, on a établi que modifier des commits déjà envoyés — c'est une mauvaise idée. Mais que faire si vous avez malgré tout modifié votre historique local (par exemple avec Reset) et qu'il diverge maintenant de l'historique sur le serveur ? En tentant de faire un push normal, Git va renvoyer une erreur, protégeant l'historique commun contre l'écrasement.
Pour ces cas il existe l'option — force push (push forcé). Cette commande dit au serveur : "Oublie tout ce que tu avais. Ma version locale de l'historique est la seule vraie. Remplace ton historique par le mien".
ATTENTION ! Dans 99% des cas l'utilisation de force push dans des projets d'équipe est une catastrophe. Cela peut supprimer de façon irréversible des commits que vos collègues ont déjà récupérés et sur lesquels ils travaillent. C'est comme arracher des pages d'un livre partagé et coller les vôtres.
Quand il est strictement INTERDIT d'utiliser force push :
- Sur n'importe quelle branche partagée :
main,develop,master. Jamais. - Sur toute branche sur laquelle quelqu'un d'autre que vous travaille.
Le seul scénario acceptable :
Vous travaillez dans votre branche feature personnelle, que personne n'a encore vue ni utilisée. Vous avez fait plusieurs commits "sales", vous les avez envoyés au serveur, puis décidé de les "nettoyer" avec Reset. Dans ce cas, vous pouvez faire un force push pour mettre à jour votre branche sur le serveur avant de créer un Pull Request.
Dans l'IDE cette option est généralement cachée derrière le bouton Push. Les développeurs d'IDE l'ont fait exprès pour éviter les clics accidentels.
Si vous n'êtes pas sûr à 100% de ce que vous faites — n'utilisez jamais force push. Il est plus sûr de créer un nouveau commit avec les corrections.
6. Mise à jour du projet
Appuyez toujours sur Update Project sur la branche main avant de commencer à travailler sur une nouvelle tâche. Ça vous évitera beaucoup de conflits de merge plus tard et garantira que vous partez de la version la plus à jour du code.
GO TO FULL VERSION