Git sans peur : ton filet quand tu codes avec l'IA
Beaucoup de gens qui codent avec l'IA évitent Git par peur de tout casser. C'est l'inverse qu'il faut retenir : Git n'est pas ce qui casse ton projet, c'est ce qui le sauve. Surtout quand tu laisses l'assistant modifier quinze fichiers d'un coup — là, tu veux un filet. Voici l'essentiel, sans jargon, et de quoi t'en servir dès aujourd'hui.
Git, c'est un bouton « sauvegarder » qui voyage dans le temps
Oublie l'image du truc d'experts. Concrètement, Git prend des photos de ton projet à un instant donné. Chaque photo — on dit un commit — est un point de sauvegarde auquel tu peux revenir.
Pense à un jeu vidéo : tu avances, tu sauvegardes, tu avances encore, tu sauvegardes. Si une séquence tourne mal, tu recharges la dernière sauvegarde et tu n'as rien perdu. Ton projet devient une ligne de save points, pas un fichier fragile que tu pourrais bousiller d'une fausse manip.
Et c'est exactement ce qui change tout en vibecoding : avant de lâcher l'IA sur une grosse modif, tu fais une sauvegarde. Si le résultat est moins bon, tu recharges. Tu codes sans filet aujourd'hui ? C'est ça, le vrai risque — pas Git.
Quatre commandes, et tu tiens la base
Le quotidien tient dans une petite boucle. Image utile : ton prochain commit est une boîte que tu remplis, fermes et étiquettes.
git status— « où j'en suis, qu'est-ce qui a changé ? » C'est ton tableau de bord. Aucun effet de bord, tu peux le lancer cent fois par jour.git add .— mets toutes tes modifs dans la boîte.git commit -m "..."— ferme la boîte et colle une étiquette qui dit ce que tu as fait.git push— envoie une copie sur GitHub, à l'abri de ta machine.
En vrai, ça donne :
git status git add . git commit -m "Ajoute le formulaire de contact" git push
C'est tout. (Un aparté utile : un fichier .gitignore garde hors de tes commits ce qui n'a rien à y faire — tes secrets, node_modules.) Deux bonus en lecture seule, sans danger : git log --oneline liste tes points de sauvegarde, et git diff te montre ligne par ligne ce qui a bougé. Regarder ne casse jamais rien.
Commiter souvent : ton filet quand l'IA touche à tout
Si tu ne retiens qu'une habitude, c'est celle-là : commite souvent. Dès que quelque chose marche, sauvegarde. Avant de demander à l'IA un gros changement multi-fichiers, sauvegarde. Quand ça remarche, sauvegarde encore.
La logique est simple : la distance entre deux commits, c'est ce que tu risques de perdre. Tu commites une fois par jour ? Revenir en arrière coûte une journée. Tu commites à chaque étape qui marche ? Revenir coûte quelques minutes. Des petits commits fréquents te donnent une marche arrière fine et indolore.
Le réflexe de pro que je garde quand l'IA vient de toucher quinze fichiers : avant de valider, je regarde le diff. Pas ligne par ligne religieusement, mais assez pour savoir ce que je sauvegarde. On ne commite pas en aveugle un changement qu'on n'a pas au moins survolé. Et pour le message, pas de stress : trois mots qui décrivent l'intention suffisent — l'IA peut même te l'écrire.
Annuler une bêtise sans paniquer
La bonne nouvelle, c'est que la plupart des catastrophes imaginées n'en sont pas. Le scénario courant : depuis ton dernier commit, tout est parti en vrille (souvent parce qu'une grosse modif IA a mal tourné). Tu veux juste revenir au dernier état propre.
git restore .
Cette commande jette les modifications non commitées et te ramène à ton dernier point de sauvegarde. Oui, elle efface ce que tu n'avais pas commité — et c'est précisément pourquoi commiter souvent rend l'opération quasi gratuite : tu ne perds que les dernières minutes.
Besoin de retrouver un état plus ancien ? git log --oneline te montre tous tes commits ; chacun est un point auquel tu peux revenir. Et garde ça en tête, ça déstresse : ce qui est commité est remarquablement difficile à perdre pour de bon. Git conserve bien plus d'historique qu'on ne croit.
Une franchise de pro pour finir : il existe quelques commandes vraiment tranchantes (git reset --hard, le push forcé). Ce sont les seules à apprendre lentement — et tu n'en as pas besoin pour la boucle quotidienne. status, add, commit, push, restore : tu peux t'appuyer dessus les yeux fermés.
Les branches, en deux mots
Une branche, c'est une copie parallèle de ton projet où tu peux tenter un truc sans toucher à la version qui marche. Ta version de référence s'appelle main.
Tu veux laisser l'IA explorer une grosse idée sans risque ? git checkout -b test-idee crée un bac à sable. Si c'est concluant, tu fusionnes ; sinon, tu jettes la branche et main n'a jamais bougé. Honnêtement, en solo et en débutant, tu vas très loin sur main avec des commits fréquents — les branches, c'est l'outil d'après, quand tu en sens le besoin. Pas une case obligatoire.
En résumé
Git n'est pas un piège à éviter, c'est le filet qui te laisse oser. Retiens la boucle — status, add, commit, push —, commite à chaque fois que quelque chose marche, jette une bêtise non commitée avec git restore ., et garde les branches pour quand tu voudras isoler une expérience. Laisser l'IA travailler vite parce que tu as toujours un point de retour : c'est exactement ça, vibecoder comme un pro.