Git : votre filet de sécurité

Vous savez maintenant cadrer un projet (Module 3) et diriger l’IA (Module 4). Reste à vous protéger. Car l’IA, si elle code vite, peut aussi casser vite. Ce module installe le filet de sécurité sans lequel aucune expérimentation n’est sereine : Git. Prenez-le au sérieux, et vous n’aurez plus jamais peur de « laisser essayer » l’IA.

Pourquoi Git est non négociable en vibe coding

Git est un système qui enregistre l’historique de votre projet. À chaque étape importante, vous prenez une « photo » de l’état du code (un *commit*). Vous pouvez ensuite revenir à n’importe quelle photo précédente, comparer deux versions, ou travailler sur une copie sans toucher à l’original.

En développement classique, Git est déjà essentiel. En vibe coding, il devient vital : un prompt malheureux, une réécriture trop large, et voilà un projet qui fonctionnait devenu instable. Sans Git, aucun moyen fiable de revenir à l’état d’avant. Avec Git, c’est une seule commande.

On ne lance pas une session de vibe coding sur un projet qui n’est pas sous Git. C’est la première chose à mettre en place, avant même d’écrire du code.

Committer souvent : pourquoi et comment

Un *commit* est un point de sauvegarde. La bonne pratique en vibe coding : committer souvent, à chaque étape qui fonctionne. Pourquoi si souvent ? Parce que chaque commit est un point de retour sûr. Si vous committez après chaque fonctionnalité validée, alors quand l’IA casse quelque chose, vous ne perdez au pire que la dernière étape — pas toute votre journée. Le cycle idéal :

1. 1Demander une modification précise à l’IA.
2. 2Tester que ça fonctionne.
3. 3Relire les changements (le diff).
4. 4Committer avec un message clair : « Ajout de la section Avis clients ».
5. 5Passer à l’étape suivante.

# Enregistrer une étape qui fonctionne
git add .
git commit -m "Ajout de la section Avis clients"

# Voir l'historique de vos "photos"
git log --oneline

Un bon message de commit décrit ce qui a changé et pourquoi, en une phrase. Votre futur vous (et l’IA) vous remerciera de pouvoir relire l’histoire du projet comme un récit clair plutôt qu’une suite de « modifs diverses ».

Les branches : isoler chaque expérimentation

Une *branche* est une copie parallèle de votre projet sur laquelle travailler sans toucher à la version principale (souvent `main`). Si l’expérimentation réussit, vous la *fusionnez* dans `main`. Si elle échoue, vous la jetez — sans aucune conséquence sur la version stable. C’est idéal pour les idées risquées : « et si je testais une refonte complète de la page d’accueil ? »

Pour un débutant travaillant seul, une règle simple suffit : `main` reste toujours dans un état qui fonctionne, et toute expérimentation un peu large se fait sur une branche.

Revenir en arrière sans paniquer

C’est le superpouvoir que Git vous donne. Selon les situations :

• Annuler des modifications non commitées : l’IA a modifié des fichiers, le résultat ne convient pas → revenir au dernier commit et effacer ces changements.
• Revenir à un commit précédent : le projet marchait il y a trois commits, plus maintenant → remonter à l’état qui marchait.
• Comparer deux versions : voir exactement ce qui a changé entre « ça marchait » et « ça ne marche plus », ce qui aide à diagnostiquer.

Vous n’avez pas besoin de tout connaître par cœur : demandez à Claude la bonne commande — « Comment annuler mes modifications non commitées pour revenir au dernier commit ? » — à condition de comprendre ce qu’elle fait avant de l’exécuter. Certaines commandes (comme `git reset --hard`) suppriment définitivement du travail.

Lire un diff : la compétence la plus rentable

Un *diff* est la liste des différences introduites par une modification : lignes ajoutées, supprimées, modifiées. Relire le diff avant chaque commit est peut-être le réflexe le plus rentable de tout le vibe coding. C’est là que vous attrapez :

• les modifications que vous n’aviez pas demandées (l’IA qui « déborde ») ;
• les suppressions accidentelles de code qui fonctionnait ;
• les incohérences et erreurs manifestes ;
• les secrets accidentellement ajoutés (clés API, mots de passe — Module 7).

Vous n’avez pas besoin de comprendre chaque ligne dans le détail : repérez ce qui ne devrait pas être là. GitHub ajoute à Git une dimension précieuse — une sauvegarde en ligne, une interface visuelle pour lire les diffs confortablement, et la base du déploiement continu (Module 9). Git est le filet ; GitHub, le coffre-fort.