Sur mon-premier-site, revenir en arrière après une modification décevante ne demandait qu'à retaper le texte à la main : le projet est minuscule. Sur un vrai projet, plus grand, ce filet de sécurité manuel ne suffit plus. Git, présenté brièvement ici et couvert en détail dans le parcours Git & GitHub de Web-Shine Docs, résout précisément ce problème.

Git ne remplace pas Gemini, et inversement

Gemini CLI aide à lire, comprendre et modifier du code. Git enregistre l'historique de ces modifications, sous forme de points de sauvegarde appelés commits, que vous pouvez comparer ou retrouver à tout moment. Les deux outils sont complémentaires, pas concurrents : Git ne sait pas écrire de code à votre place, et Gemini ne garde pas d'historique fiable de vos fichiers dans le temps.

Avant une tâche importante : un état propre

Avant de confier une tâche un peu ambitieuse à Gemini, en particulier une qui pourrait toucher plusieurs fichiers, vérifiez l'état de votre dépôt Git.

Si ce résultat n'est pas encore familier, en particulier la notion de « working tree clean », le parcours Git & GitHub de Web-Shine Docs y consacre plusieurs guides détaillés. Ce qui compte ici : un état propre signifie que tout votre travail précédent est déjà enregistré, ce qui rend une comparaison future beaucoup plus simple.

Si des modifications existent encore, préparez-les et enregistrez-les avant de continuer.

Un message de commit comme celui-ci, qui indique explicitement qu'il s'agit d'un point de contrôle avant une intervention de l'IA, rendra votre historique plus lisible si vous devez y revenir plus tard.

Après l'intervention de Gemini : comparer avant de valider

Une fois que Gemini a terminé sa tâche, relancez git status pour voir précisément quels fichiers ont changé.

Si vous voyez apparaître un fichier que vous n'attendiez pas dans cette liste, c'est le signal exact que la relecture attentive, pratiquée depuis le guide 10, vient de vous éviter de valider aveuglément quelque chose d'imprévu. La commande git diff, elle, affiche le détail précis des lignes changées, fichier par fichier, ce qui complète parfaitement la lecture proposée directement par Gemini CLI dans le terminal.

Testez avant de committer

Avant de créer un nouveau commit, testez réellement le résultat, par exemple en ouvrant index.html dans un navigateur, comme au guide 10. Un commit ne signifie pas « c'est forcément correct », seulement « c'est enregistré ». Ne validez ce nouveau point d'historique qu'une fois le résultat vérifié.

Et si le résultat ne convient pas ?

Si vous n'avez pas encore committé, une commande comme git restore, suivie du nom du fichier, permet d'annuler des modifications non enregistrées et de retrouver le contenu du dernier commit. C'est précisément pour cette raison qu'un état propre avant de commencer, comme recommandé plus haut, est si précieux : il donne un point de retour fiable, sans ambiguïté sur ce qui appartenait à votre travail précédent et ce qui vient d'être ajouté.

Une commande à ne jamais utiliser en réflexe

Ne tapez jamais git reset --hard ou une suppression massive de fichiers comme réaction automatique à un résultat décevant de Gemini. Ces commandes peuvent effacer un travail que vous vouliez en réalité conserver. Prenez le temps de lire précisément ce qui a changé avant de choisir comment revenir en arrière.

Vérifiez que vous avez compris

Vous lancez une tâche Gemini sur un projet où git status affichait déjà plusieurs fichiers modifiés avant même de commencer. Après la tâche, pourrez-vous distinguer facilement ce que Gemini vient de changer de ce que vous aviez déjà modifié vous-même auparavant ?

Non, pas facilement. C'est exactement pour cette raison que ce guide recommande de partir d'un état propre, confirmé par « nothing to commit, working tree clean », avant une tâche importante. Sans ce point de départ net, les modifications de Gemini se mélangent avec les vôtres, et la comparaison perd une grande partie de son utilité.

Chapitre terminé