Git pour vibecoder : le filet de sécurité que j'aurais aimé avoir dès le début

J'ai perdu du code. Pas à cause d'un crash. Pas à cause d'un bug. Parce que j'ai laissé l'IA commit à ma place.

Je m'explique. J'avais un workflow Git propre. Branches, commits réguliers, tout ça. Sauf que je laissais Claude faire les commits. Et un jour, il a supprimé un fichier. Un fichier qui n'avait jamais été committé. Parce que l'IA n'avait pas tout sauvegardé depuis le début.

Disparu. Irrécupérable.

Ce jour-là, j'ai compris un truc : Git n'est pas un outil de process pour le vibecoder. C'est un filet de sécurité. Et il faut au minimum savoir comment il fonctionne avant de tout déléguer à l'IA. Ca tombe bien c'est ce qu'on va faire aujourd'hui. Et si tu débarques ici sans contexte, je raconte ce qu'est le vibecoding dans un autre article.

Pourquoi Git quand on vibecode

Quand tu vibecodes, l'IA modifie 10, 20, 50 fichiers d'un coup. Tu ne vois pas tout ce qu'elle fait. Surtout si tu utilises un IDE en terminal comme Claude Code.

Et tu découvres les dégâts 30 minutes plus tard. Quand plus rien ne marche.

Git te permet de :

• Sauvegarder ton code à un instant T (commit)
• Revenir en arrière si l'IA a fait n'importe quoi (restore/revert)
• Envoyer ton code dans le cloud pour le déployer et le sauvegarder hors de ta machine locale (push)

C'est une machine à remonter le temps.

Les 5 concepts à comprendre (pas plus)

Git fait peur. Plein de commandes, des conflits, des branches... En fait, tu n'as besoin que de 5 concepts pour vibecoder sereinement.

Tu n'as pas besoin de branches, de merge, de stash pour débuter. Ces 5 concepts suffisent pour 95% des situations.

Les 3 façons de démarrer un projet

Là aussi, y'a des raccourcis.

Le template, c'est le game changer. Tu crées ta stack une fois (CLAUDE.md, rules, .gitignore, structure de dossiers), tu la configures comme template sur GitHub, et tu la réutilises pour chaque nouveau projet.

Plus besoin de reconfigurer ton environnement à chaque fois. Un clic, et t'as ton projet prêt.

Trouvaille en écrivant cet article : j'ai découvert PGBackWeb, un outil de backup PostgreSQL/Supabase. Parce que Git sauve ton code, mais pas ta base de données. Si tu casses ta DB Supabase, Git ne pourra rien pour toi. Je l'ai testé depuis, et je l'ai gardé sur toutes mes apps en production.

Mon workflow quotidien

Maintenant que tu sais démarrer, voyons le workflow de tous les jours.

Ce que font les devs traditionnels : une branche par feature, des pull requests, du code review par un collègue, un merge après validation...

Ce que je fais en solo :

• Tout sur main (pas de branches pour chaque feature)
• Commits toutes les 10-30 minutes. Je demande à l'IA de commit après chaque grosse feature mais par précaution je commit parfois en mode "sauvage" juste au cas ou l'IA ferait n'importe quoi.
• Push quand ça marche en local
• npm run build AVANT de push (pour vérifier que ça compile)

Pourquoi tout sur main ? Parce que tu veux déployer vite, pas passer du temps à gérer des branches. C'est ce qu'on appelle le "trunk-based development". Recommandé pour les devs solo.

Et le push n'est pas un aboutissement, c'est un déclencheur : mon serveur écoute GitHub, donc dès que je pousse, la nouvelle version part en ligne toute seule. Je commite, je pousse, c'est déployé. C'est ça qui rend la boucle agréable, et ça mérite son propre article.

Ces consignes, tu les écris une fois dans ton CLAUDE.md et tu n'y reviens plus.

Mon astuce pour les commits : j'utilise des timestamps au lieu de messages parfaits.

20251208143052
20251208144523
20251208150312

J'ai un snippet Raycast qui génère ça automatiquement.

Pas de temps perdu à réfléchir au message. Tu as un historique granulaire pour revenir précisément en arrière. De toute façon, c'est pas toi qui vas fouiller dans tes commits, c'est l'IA, donc c'est pas très grave si c'est "mal rangé".

Ma stack Git :

Pas de MCP GitHub. La CLI gh suffit et coûte moins de tokens. Tu l'installes avec brew install gh, tu t'authentifies une fois avec gh auth login, et c'est réglé.

Les 2 façons de récupérer d'une erreur

Ce workflow marche 99% du temps. Mais quand l'IA casse tout, il faut savoir récupérer.

1 fichier cassé → Restore

L'IA a cassé un composant, mais le reste marche.

Dans GitHub Desktop :

1. Onglet "Changes"
2. Clic droit sur le fichier cassé
3. "Discard changes"

Tu récupères juste ce fichier. Le reste de ton travail est préservé.

Tout cassé → Revert

L'IA a modifié 20 fichiers et plus rien ne marche. Solution nucléaire.

Dans GitHub Desktop :

1. Onglet "History"
2. Trouve le dernier commit qui a cassé les choses
3. Clic droit → "Revert changes in commit"

Ça crée un nouveau commit qui annule les changements. L'historique reste intact.

Le piège des secrets

Et il y a un piège encore plus vicieux que l'IA qui casse ton code : les secrets.

Stat choc : 39 millions de secrets ont été exposés sur GitHub en 2024. Le chiffre vient de GitHub, qui l'a publié début 2025. API keys, mots de passe, tokens...

Le problème : une fois qu'un secret est committé, il est dans l'historique Git pour toujours. Même si tu supprimes le fichier après.

Des bots scannent GitHub en temps réel et exploitent les secrets en quelques minutes.

La solution :

1. Crée ton .gitignore AVANT le premier commit
2. Mets .env dedans (et tous les fichiers secrets)
3. Crée un .env.example qui liste les variables nécessaires sans les valeurs

# .env.example (à commiter)
DATABASE_URL=
STRIPE_SECRET_KEY=
OPENAI_API_KEY=

Comme ça, un nouveau dev (ou toi dans 6 mois) sait quoi configurer.

Protection automatique : installe Gitleaks. Ça scanne ton code et bloque le commit si un secret est détecté.

brew install gitleaks  # macOS

J'ai aussi rajouté un hook qui empêche Claude Code de sauter Gitleaks. Parce que sinon il le contourne.

Si tu commites un secret par erreur :

1. RÉVOQUER immédiatement (dashboard API, Stripe, etc.)
2. Générer un nouveau secret
3. Supprimer le fichier ne suffit pas (il reste dans l'historique)

Ce que j'aurais aimé savoir

Git n'est pas un outil de développeur traditionnel pour toi. C'est ton filet de sécurité.

• Commits fréquents = plein de points de sauvegarde
• GitHub Desktop pour interagir manuellement avec Github (ne fais pas confiance à l'IA pour ça)
• Templates pour construire plus vite
• Revert, jamais reset --hard
• .gitignore avant le premier commit

L'IA est puissante. Mais elle oublie de commiter des fichiers. Elle utilise des commandes dangereuses. Elle ne protège pas tes secrets.

Toi, tu gardes le contrôle.

Si tu ne fais qu'un truc après avoir lu ça : ouvre ton projet en cours et vérifie que ton .env est bien dans le .gitignore. Ça prend 30 secondes.

Besoin d’un coup de main pour cette partie technique ?

Je sais que parfois, même bien expliqué, un workflow reste intimidant.
Si tu préfères qu’on le mette en place ensemble, contacte-moi : je suis freelance en automatisation, et je peux t’aider à passer de “je devrais le faire” à “c’est déjà en place”.

Sinon, continue de piocher dans les ressources du site, elles sont faites pour ça ✌️