Utiliser Git avant une tâche importante | Cursor

Sur mon-premier-site, un projet minuscule, revenir en arrière après un changement décevant demandait tout au plus de retaper une ligne à la main. Sur un 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épond précisément à ce besoin.

Git et Cursor sont complémentaires, pas concurrents

Cursor aide à lire, comprendre et modifier du code, avec ou sans l'aide de l'Agent. Git enregistre l'historique de ces modifications sous forme de commits, que vous pouvez comparer ou retrouver à tout moment. L'un ne remplace pas l'autre : Cursor ne garde pas d'historique fiable de vos fichiers dans le temps, et Git ne sait pas écrire de code à votre place.

Avant une tâche importante : un état propre

Ouvrez le terminal intégré, pratiqué au guide 12, et vérifiez l'état de votre dépôt avant de confier une tâche ambitieuse à l'Agent, en particulier une qui toucherait plusieurs fichiers à la fois.

terminal intégré

$ git status

On branch main

nothing to commit, working tree clean

Si ce résultat ne vous est pas encore familier, le parcours Git & GitHub de Web-Shine Docs y consacre plusieurs guides détaillés, depuis la toute première notion jusqu'aux branches et à GitHub. Ce qui compte ici : un état propre signifie que tout votre travail précédent est déjà enregistré, ce qui donne un point de comparaison fiable pour la suite.

Si des modifications sont encore en attente, enregistrez-les d'abord.

terminal intégré

$ git add index.html style.css

$ git commit -m "État avant tâche Cursor plus ambitieuse"

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

Une fois la tâche terminée et les changements acceptés dans Cursor, relancez git status pour voir précisément quels fichiers ont été touchés.

terminal intégré

$ git status

On branch main

Changes not staged for commit:

modified: index.html

modified: style.css

Si un fichier apparaît dans cette liste sans que vous l'attendiez, c'est le signal exact que la lecture attentive du diff, pratiquée depuis le guide 8, vient de vous éviter une surprise. La commande git diff affiche le détail précis des lignes changées, fichier par fichier, ce qui complète parfaitement la revue déjà proposée directement dans l'interface de Cursor.

Testez avant de committer

Avant de créer un nouveau commit, testez réellement le résultat, 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 point d'historique qu'une fois le résultat vérifié.

terminal intégré

$ git add index.html style.css

$ git commit -m "Ajoute la section de présentation avec Cursor"

Et si le résultat ne convient pas ?

Si vous n'avez pas encore committé, git restore, suivi du nom d'un fichier, annule des modifications non enregistrées et retrouve le contenu du dernier commit. C'est précisément pour cette raison qu'un état propre avant de commencer est si précieux : il fournit un point de retour fiable, sans ambiguïté entre votre travail précédent et ce que l'Agent vient d'ajouter.

Une commande à ne jamais utiliser en réflexe

N'utilisez jamais git reset --hard comme raccourci automatique face à un résultat décevant, sans avoir compris précisément quels fichiers seraient perdus. Prenez le temps de lire ce qui a changé avant de choisir comment revenir en arrière, sur une branche partagée comme sur un projet personnel.

Ce que vous savez faire maintenant

Vous savez ouvrir un projet dans Cursor, vous repérer dans son interface, poser une question à l'Agent, lui donner du contexte, lire un diff avant de l'accepter, utiliser Tab et l'édition en ligne, construire et faire évoluer un petit projet avec méthode, utiliser le terminal intégré avec prudence, décider d'une permission, écrire une Rule utile, et vous appuyer sur Git avant une tâche importante. Ce sont exactement les compétences qui distinguent un usage prudent et contrôlé de Cursor d'un usage qui subit les propositions de l'IA sans les comprendre.

Vérifiez que vous avez compris

Vous lancez une tâche ambitieuse avec l'Agent 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 Cursor vient de changer de ce que vous aviez déjà modifié vous-même ?

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 l'Agent se mélangent avec les vôtres, et la comparaison perd une grande partie de son utilité.