Git avec Codex : travailler en sécurité

Introduction

Imaginez que vous écriviez un roman. À chaque fois que vous changez d'avis sur la fin de l'histoire, vous dupliquez votre fichier : roman.doc, roman_v2.doc, roman_v2_final.doc, roman_v2_final_vrai.doc.

En programmation, faire cela est un aller simple vers la folie. Git a été créé précisément pour éviter cela. C'est l'outil qui sauve le plus de temps et de cheveux aux développeurs.

Lorsqu'on utilise une intelligence artificielle puissante comme Codex, capable de modifier 15 fichiers en une minute, on ne peut pas travailler sans filet de sécurité. Ce chapitre va démystifier Git et vous donner la "ceinture de sécurité" indispensable pour expérimenter sans stress.

Qu'est-ce que Git ?

Git n'est pas un langage de programmation. C'est un logiciel qui s'installe sur votre ordinateur (souvent déjà présent sur Mac/Linux) et qui se comporte comme une machine à remonter le temps photographique.

Quand vous lui dites "Prends une photo de mon dossier", Git enregistre chaque virgule, chaque image, chaque fichier. Si demain vous détruisez tout votre projet par erreur, il vous suffit d'un claquement de doigts pour dire à Git : "Remets les fichiers exactement comme sur la photo d'hier".

Pourquoi utiliser Git avec Codex ?

Parce que Codex ne lit pas dans vos pensées. Parfois, il va mal comprendre votre demande et supprimer une fonctionnalité essentielle. Si vous avez Git, vous souriez et vous annulez. Si vous n'avez pas Git, vous pleurez.

Les principaux termes à connaître

Le jargon de Git peut faire peur. Dédramatisons-le immédiatement.

Créer son premier dépôt Git (L'initialisation)

Pour que Git commence à surveiller un projet, il faut le lui demander. Cela ne se fait qu'une seule fois par projet.

1. Ouvrez votre projet dans VS Code.
2. Ouvrez le terminal de VS Code.
3. Tapez cette commande et appuyez sur Entrée :
   

   git init

C'est tout ! Le terminal vous répondra Initialized empty Git repository. Un dossier invisible .git a été créé. Git est réveillé et vous regarde travailler.

Réaliser son premier commit (La photo de sauvegarde)

Vous avez un site qui fonctionne. Vous voulez prendre une photo pour immortaliser ce moment parfait.

Étape 1 : Préparer les fichiers (La salle d'attente)

git add .

Le point . signifie "Prends TOUS les fichiers modifiés". C'est comme dire aux acteurs "Placez-vous devant l'appareil photo".

Étape 2 : Prendre la photo (Le Commit)

git commit -m "Site fonctionnel avec page d'accueil"

Le paramètre -m signifie Message. C'est crucial : c'est le nom de votre photo. Dans un mois, vous devrez savoir à quoi correspond cette sauvegarde.

Utiliser Codex avec Git en situation réelle

Voici le scénario idéal de travail (le Workflow) :

graph TD;
    A[Projet sain] --> B[Commit: 'Base propre'];
    B --> C[Demande à Codex: 'Crée un Mode Sombre'];
    C --> D[Codex modifie le code];
    D --> E{Test: Le mode sombre est-il beau ?};
    E -- Oui --> F[Commit: 'Ajout Mode Sombre'];
    E -- Non, tout est cassé --> G[git restore .];
    G --> A;

Si la modification est un succès, vous "sauvegardez la partie". Si c'est un échec critique, vous rechargez la sauvegarde précédente. C'est le principe du jeu vidéo appliqué au code.

Revenir à une version précédente (Le Ctrl+Z ultime)

Le cas de l'erreur non sauvegardée :

Vous venez de demander à Codex de refaire le CSS. C'est hideux. Vous n'avez pas encore fait de git commit. Tapez :

git restore .

Instantanément, tous vos fichiers reviennent à l'état de votre dernier commit valide. C'est magique.

Le cas du commit toxique :

Vous avez fait le commit "Ajout du paiement Stripe". Mais le lendemain, vous réalisez que ça a complètement détruit le panier d'achat. Demandez à Codex de vous fournir la commande git revert correspondant à ce commit (il l'analysera avec vous) pour l'annuler proprement.

Les bonnes habitudes

Les erreurs les plus fréquentes avec Git

• Symptôme : fatal: not a git repository
  Cause : Vous avez oublié de faire git init lors de la création du projet.
  Bonne pratique : Le faire dès la première seconde.
• Symptôme : Un commit avec 450 fichiers modifiés, dont 440 ne sont pas du code (images, fichiers de config lourds).
  Cause : Vous avez oublié le fichier .gitignore (souvent pour le dossier node_modules).
  Bonne pratique : Demandez à Codex de générer un fichier `.gitignore` standard.
• Symptôme : Avoir peur du terminal.
  Cause : Vous pensez que c'est du "vrai piratage".
  Bonne pratique : Utilisez le bouton "Source Control" dans la barre latérale gauche de VS Code. C'est une interface graphique intuitive pour faire git add (+) et git commit (champ texte + bouton Valider).
• Symptôme : "Je croyais que Git allait tout sauvegarder sur internet automatiquement."
  Cause : Confusion entre Git (local) et GitHub (internet).
  Bonne pratique : Comprenez que sans la commande git push, rien ne quitte votre ordinateur.
• Symptôme : Vous avez copié/collé des commandes Git de StackOverflow sans les comprendre, votre code a disparu.
  Cause : L'utilisation aveugle de commandes destructrices comme git reset --hard.
  Bonne pratique : Toujours demander à Codex d'expliquer une commande Git AVANT de la taper.

Atelier pratique

Entraînez-vous sur un projet factice (un dossier avec juste un fichier index.html) pour ne pas stresser.

Conseils

Tableau récapitulatif des commandes

Foire aux questions

À retenir

Transition vers le chapitre suivant

Vous êtes maintenant en sécurité absolue. Vous pouvez générer du code, vous tromper et annuler. Ce super-pouvoir va vous permettre d'aborder une tâche très pointue.

Souvent, le code généré par l'IA ou par vous-même "fonctionne", mais il est laid, lourd ou mal structuré. Dans le prochain chapitre, nous allons apprendre à utiliser Codex pour refactoriser intelligemment votre code : l'art de nettoyer, simplifier et optimiser un projet sans jamais modifier ce que voit l'utilisateur final.