Git et GitHub

Git, c'est la mémoire du projet

Un agent qui modifie dix fichiers en dix minutes, c'est puissant — et vertigineux : comment revenir en arrière si le résultat ne plaît pas ? Git répond à cette question. Il enregistre des points de retour nommés, que l'on peut relire, comparer et restaurer. GitHub, lui, met ces points de retour à l'abri : le travail existe ailleurs que sur votre machine.

• Sans Git, pas d'annulation fine : /undo dans OpenCode s'appuie sur Git. C'est le filet de sécurité du pilotage par IA.
• Sans Git, pas d'histoire : on ne sait plus ce qui a été fait, quand, ni pourquoi. Le projet devient un fichier inconnu qu'on n'ose plus toucher.
• Sans GitHub, pas de sauvegarde : un disque qui rend l'âme, et tout disparaît — y compris la trace des prompts.

Le vocabulaire, en images

Les commandes essentielles

Onze commandes suffisent pour tout le projet. Les autres existent, mais ne les apprenez pas « au cas où » : elles viendront quand vous en aurez besoin.

La première fois, pas à pas

1. Installer Git et se présenter. Le nom et l'adresse apparaissent dans chaque commit : ce sont eux qui rendent l'historique lisible.

   git --version
   git config --global user.name "Prénom Nom"
   git config --global user.email "adresse@exemple.fr"

2. Créer le dépôt GitHub — privé. Sur github.com : New repository, un nom court (mon-projet), visibilité Private. Ne cochez rien d'autre : ni README, ni .gitignore, ni licence. Ces cases créent un historique que votre dossier local ne connaît pas, et le premier push sera refusé.
3. Initialiser le dépôt local dans le bon dossier.

   cd mon-projet
   git init
   git status          # doit afficher le dossier du projet

4. Créer le .gitignore AVANT le premier commit.

   .env
   .env.*
   !.env.example
   node_modules/
   dist/

   Vérification indispensable : git check-ignore .env doit afficher .env. Sinon, ne committez pas encore.
5. Enregistrer le premier point de retour.

   git add -A
   git status          # relire la liste des fichiers préparés
   git commit -m "Initialise le projet : page d'accueil et .gitignore"

6. Relier au dépôt GitHub et pousser. Deux méthodes courantes :

   # Méthode recommandée : GitHub CLI (installe aussi l'authentification)
   gh auth login
   git remote add origin git@github.com:compte/mon-projet.git
   git push -u origin main
   
   # Méthode classique : clé SSH créée à la main, ajoutée à GitHub
   ssh-keygen -t ed25519 -C "adresse@exemple.fr"

   GitHub n'accepte plus le mot de passe du compte en ligne de commande : il faut une clé SSH ou un jeton. Un push refusé n'est pas une panne, c'est un problème d'identité.
7. Vérifier en ligne. Rechargez la page GitHub : les fichiers et le message du commit doivent apparaître. Le travail est maintenant à l'abri.

Le cycle de travail

Une fois les bases posées, le travail tourne toujours selon la même ronde :

1. Modifier. On demande une petite évolution à l'agent (une intention, pas trois).
2. Tester. On regarde le résultat dans le navigateur. Si c'est cassé : /undo ou correction ciblée.
3. Relire. git status puis git diff : quels fichiers ont changé, et est-ce bien ce qu'on voulait ?
4. Committer. git add puis git commit -m "verbe + objet" : un point de retour bien nommé.
5. Pousser. git push : le travail quitte la machine et devient récupérable.

Les messages de commit

Un message de commit s'adresse à la personne qui lira l'historique — c'est-à-dire vous, dans trois semaines. La formule : verbe à l'impératif + objet du changement.

Ce qui ne va jamais dans un dépôt

La checklist avant de pousser

• git status ne montre que des fichiers voulus (pas de brouillon, pas de capture).
• .env n'apparaît nulle part : ni dans les fichiers, ni dans l'historique.
• Le message de commit décrit le changement, en une phrase.
• Le dépôt est privé (ou assumé public).
• Le travail important est pushé : il existe ailleurs que sur la machine.

Six pièges à connaître

Pour aller plus loin