Outils du professionnel et résolution des problèmes

Jusqu’à présent, nous avons envisagé un scénario idéal : vous écrivez du code, vous faites des commits, vous créez une Pull Request. Mais dans la vraie vie, il arrive souvent que quelque chose se passe mal : vous pouvez introduire une erreur dans le code, faire un commit avec un message incorrect ou simplement réaliser que vous n’êtes pas parti dans la bonne direction. Dans cette leçon, nous allons voir comment résoudre les problèmes les plus courants.

1. Rollback — annulation des modifications avant le commit

Scénario : vous avez modifié un fichier, mais vous vous rendez compte que toutes vos corrections sont incorrectes et vous voulez rapidement ramener le fichier à l’état dans lequel il se trouvait après le dernier commit.

Utilisez la fonction Rollback :

1. Ouvrez l’onglet Commit.
2. Trouvez dans la liste le fichier modifié que vous souhaitez « annuler ».
3. Cliquez dessus avec le bouton droit de la souris et choisissez Rollback.

L’IDE vous avertira que les modifications seront perdues. Confirmez, et le fichier reviendra instantanément à sa dernière version enregistrée dans Git. C’est le moyen le plus simple et le plus sûr d’annuler des modifications locales.

2. Reset — suppression de commits locaux

Scénario : vous avez effectué un ou plusieurs commits, mais vous n’avez pas encore fait de push. Vous vous êtes rendu compte que ces commits sont erronés et vous voulez les supprimer complètement, comme s’ils n’avaient jamais existé.

Utilisez la fonction Reset :

1. Ouvrez l’onglet Git -> Log pour voir l’historique des commits.
2. Trouvez le dernier « bon » commit sur lequel vous souhaitez revenir (celui qui était avant les erronés).
3. 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 réinitialisation. Le plus radical — Hard.

Attention ! Le mode Hard supprime irrémédiablement tous les commits après celui choisi, ainsi que toutes les modifications de code présentes dans ces commits. Utilisez-le avec une grande prudence et uniquement pour des commits que personne n’a encore vus (ceux qui n’ont pas été envoyés sur GitHub).

3. Que faire après Push ?

Scénario : vous avez fait un push, et ce n’est qu’ensuite que vous y avez décelé une erreur.

Dès qu’un commit est poussé sur le serveur distant, il devient partie prenante 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 aient déjà récupéré vos modifications et commencé leur travail dessus.

La solution correcte et sûre :

Faites simplement un nouveau commit qui corrige l’erreur et poussez-le. C’est une pratique tout à fait normale. Ainsi, l’historique reste honnête et compréhensible pour tout le monde.

4. Remonter dans le passé: utilisation avancée du journal

Nous connaissons déjà l’onglet Git -> Log, mais ce n’est pas qu’une simple liste de commits, c’est aussi un puissant outil d’enquête.

• Hachage de commit (Commit Hash): vous avez sûrement remarqué dans le log une chaîne de lettres et de chiffres, par exemple a1b2c3d. Ce hachage est unique, il permet de faire référence précisément à n’importe quel point de l’historique du projet. Vous aurez rarement à l’utiliser manuellement, mais il est important de savoir qu’il s’agit de l’identifiant unique de chaque « instantané » de votre code.
• Vous pouvez filtrer l’historique par branche, auteur, date ou même par mot dans le message de commit. Cela aide à trouver rapidement qui a travaillé sur une partie fonctionnelle donnée et quand.
• Vous voulez trouver le commit dans lequel une ligne de code précise a été ajoutée ou supprimée? Dans la fenêtre Log, il existe un champ de recherche qui ne parcourt pas seulement les messages, mais aussi le contenu même des changements.
• Cliquez avec le bouton droit dans la marge de l’éditeur de code et choisissez Annotate with Git Blame. L’IDE affichera en face de chaque ligne qui l’a modifiée en dernier et dans quel commit. C’est incroyablement utile pour comprendre pourquoi le code est écrit de cette manière.

5. Zone dangereuse: Force Push

Nous avons donc établi que modifier des commits déjà poussés est une mauvaise idée. Mais que faire si vous avez quand même modifié votre historique local (par exemple avec Reset) et qu’il diverge maintenant de celui du serveur? En tentant de faire un push normal, Git renverra une erreur pour protéger l’historique commun contre la réécriture.

Pour ces cas, il existe une option — force push (envoi forcé). Cette commande dit au serveur: « Oublie tout ce que tu avais. Ma version locale de l’historique est la seule correcte. Remplace ton historique par le mien. »

ATTENTION! Dans 99 % des cas, utiliser force push dans des projets en équipe est une catastrophe. Cela peut supprimer irrémédiablement des commits que vos collègues ont déjà récupérés et sur lesquels ils travaillent. C’est l’équivalent d’arracher des pages d’un livre de bibliothèque commun et d’y coller les vôtres.

Quand il est catégoriquement INTERDIT d’utiliser force push:

• Sur toute 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 personnelle de fonctionnalité, que personne n’a encore vue ni utilisée. Vous avez fait quelques commits « brouillons », vous les avez envoyés sur le serveur, puis vous avez décidé de les « nettoyer » à l’aide de Reset. Dans ce cas, vous pouvez faire un force push pour mettre à jour votre branche sur le serveur avant de créer une Pull Request.

Dans l’IDE, cette option est généralement dissimulée derrière le bouton Push. Les développeurs de l’IDE l’ont fait intentionnellement pour éviter que vous ne l’appuyiez par inadvertance.

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 une nouvelle tâche. Cela vous évitera de nombreux conflits de fusion à l’avenir et garantira que vous commencez à travailler avec la version la plus à jour du code.