Séance 1, 9 h – 12 h 15

Environ 2 h de slides avec des « hands-on » intercalés (vous tapez dans votre terminal en même temps), puis 1 h de TP en autonomie. Le dépôt du TP, poussé sur GitHub sous le nom exact git-homework, servira au bonus.

Slides de la séance

Programme

  • Pourquoi git : l'historique, le travail à plusieurs, le retour en arrière
  • Le trio HEAD / index (staging) / working tree
  • init, status, add, commit, log, diff, .gitignore
  • Un commit est un snapshot, pas un diff
  • Les branches : un simple pointeur ; switch, merge (fast-forward ou merge commit)
  • Un conflit provoqué, et sa résolution
  • rebase : rejouer ses commits plutôt que fusionner
  • Défaire : restore, reset (soft / mixed / hard), revert, et reflog pour récupérer
  • Et dans VS Code ?
  • Fin de séance : learngitbranching et le bonus

TP : un petit projet, de la première ligne au rebase

TP GIT1 – Mon premier projet sous git

Durée : 1 h, en autonomie. Objectif : refaire seul, sur un projet à vous, tout ce que nous avons vu ce matin. Rien n'est noté ; en revanche c'est dans ce dépôt, publié sur GitHub sous le nom exact git-homework, que vous déposerez le bonus learngitbranching. La dernière étape le publie sur GitHub, en dépôt public : c'est une recette détaillée pas à pas, que nous expliquerons en GIT2.

Deux réflexes pour toute la séance : git status avant et après chaque commande, et git log --oneline --graph --all dès qu'une branche entre en jeu. Chaque étape se termine par une ligne « Vérifiez » qui vous dit ce que vous devez voir. Si ce n'est pas le cas, ne passez pas à la suite : relisez ce que git a répondu, il vous souffle presque toujours la commande qui répare.

1. Le projet

Choisissez un petit projet texte, sans dépendance : un carnet de recettes (un README.md et un dossier recettes/ avec un fichier Markdown par recette) ou un mini-script Python (main.py, un README.md, un fichier de données). Le contenu importe peu ; ce sont les commits qui comptent.

mkdir git-homework && cd git-homework
git init -b main

Créez le README.md (titre, une phrase), puis votre premier commit.

Vérifiez : git log --oneline montre exactement un commit ; git status dit nothing to commit, working tree clean.

2. Cinq commits propres

Faites grandir le projet en 4 ou 5 commits supplémentaires, un par idée : une recette, puis une deuxième, puis une correction, puis un sommaire dans le README… Chaque message commence par un verbe et décrit ce que le commit apporte (« Ajoute la recette des crêpes », pas « update »). Regardez au moins une fois git diff avant git add, et git diff --staged avant git commit.

Au passage, faites l'un des commits en n'ajoutant qu'un des deux fichiers que vous avez modifiés : c'est tout l'intérêt de l'index.

Vérifiez : git log --oneline liste 5 ou 6 commits, le plus récent en haut ; git log --stat -1 montre les fichiers du dernier.

3. .gitignore

Produisez de quoi ne pas versionner : un brouillon.tmp, et un dossier __pycache__/ avec un fichier dedans (mkdir __pycache__ && touch __pycache__/main.cpython-313.pyc, ou lancez vraiment votre script s'il importe un module à vous). git status doit les montrer en ??. Écrivez un .gitignore qui les exclut (un motif par ligne : __pycache__/, *.tmp), puis commitez le .gitignore lui-même.

Vérifiez : git status est propre alors que le fichier ignoré est toujours sur le disque (ls).

4. Une branche, un merge fast-forward

git switch -c garniture

Sur cette branche, un ou deux commits (une section « Garnitures » dans une recette, une fonction de plus dans le script). Revenez sur main, constatez que vos modifications ne sont plus là, puis fusionnez :

git switch main
git merge garniture

Vérifiez : git a affiché Fast-forward ; git log --oneline --graph --all est une ligne droite, main et garniture pointent sur le même commit. Supprimez ensuite la branche : git branch -d garniture.

5. Une seconde branche, un conflit, une résolution

Créez cuisson (ou ce que vous voulez). Sur cette branche, modifiez une ligne précise d'un fichier (par ex. le temps de cuisson) et commitez. Revenez sur main, modifiez la même ligne autrement, commitez. Puis :

git merge cuisson

Git annonce CONFLICT (content). Ouvrez le fichier, trouvez les marqueurs <<<<<<<, =======, >>>>>>>, gardez la version que vous voulez (ou une combinaison), supprimez les trois marqueurs, puis git add <fichier> et git commit (gardez le message proposé).

Vérifiez : git log --oneline --graph montre un commit de fusion à deux parents (* Merge branch 'cuisson' avec les deux traits |\) ; grep -r '<<<<<<<' . ne trouve rien.

6. Rejouer une branche avec rebase

Créez une branche dessert et faites-y un commit qui touche un fichier que main ne modifiera pas (une nouvelle recette, par ex.). Revenez sur main et faites-y un autre commit, sur un autre fichier. Les deux branches ont maintenant divergé : git log --oneline --graph --all doit montrer une fourche. Notez le hash du commit de dessert.

git switch dessert
git rebase main
git log --oneline --graph --all

Puis rapatriez la branche dans main :

git switch main
git merge dessert

Vérifiez : le rebase a affiché Successfully rebased ; le commit de dessert a un nouveau hash et se trouve au bout de main ; le merge a affiché Fast-forward ; le graphe est redevenu une ligne droite. Supprimez la branche : git branch -d dessert.

7. Annuler un commit avec revert

Choisissez un commit du milieu de l'historique (pas le merge) dont la modification est simple, par ex. la « correction » de l'étape 2, et annulez-la proprement :

git revert <hash>

Vérifiez : un nouveau commit Revert "…" est en haut de git log --oneline ; le fichier est revenu à son contenu d'avant, et l'ancien commit est toujours dans l'historique.

8. Perdre un commit, le retrouver avec reflog

Notez le hash du commit en haut de git log --oneline. Puis, exprès :

git reset --hard HEAD~1
git log --oneline          # le commit a disparu
git reflog                 # …mais pas de git

Retrouvez-le dans le reflog et ramenez main dessus : git reset --hard HEAD@{1} (ou avec le hash noté).

Vérifiez : git log --oneline est redevenu identique à ce qu'il était avant le reset ; git status est propre.

9. Publier sur GitHub, en dépôt public, sous le nom git-homework

Le cours de ce matin n'a pas parlé des dépôts distants : ce sera le programme de GIT2. Cependant, votre dépôt doit être en ligne pour le bonus, et vous l'avez déjà fait pour pe-homework. Suivez donc cette recette pas à pas ; nous verrons en GIT2 ce que fait chaque commande.

Le dépôt doit être public : je relève tous les dépôts git-homework automatiquement, sans invitation, et c'est dedans que vous déposerez le bonus. Il ne contient rien de personnel, seulement votre petit projet.

a. Vérifiez que GitHub vous reconnaît. Vos clés SSH sont en place depuis pe-homework :

ssh -T git@github.com

Vous devez lire Hi VOTRE-LOGIN! You've successfully authenticated. Si vous lisez Permission denied (publickey), vous êtes sur une machine sans clé : faites-vous aider avant de continuer.

b. Créez le dépôt vide sur GitHub.

  1. Sur https://github.com, bouton + en haut à droite, puis New repository.
  2. Repository name : git-homework, exactement, sans majuscule.
  3. Cochez Public.
  4. Ne cochez rien d'autre : pas de Add a README file, .gitignore sur None, license sur None. Votre projet existe déjà en local ; un README créé ici donnerait deux histoires sans lien, et le push serait refusé.
  5. Create repository.

GitHub affiche alors une page Quick setup. Cliquez sur SSH (et non HTTPS), puis copiez l'adresse, de la forme git@github.com:VOTRE-LOGIN/git-homework.git.

c. Envoyez votre projet. Dans le terminal, placez-vous à la racine du projet : pwd doit se terminer par git-homework, et git status doit être propre. Puis :

git remote add origin git@github.com:VOTRE-LOGIN/git-homework.git
git push -u origin main

La première ligne enregistre l'adresse du dépôt GitHub sous le nom origin. La seconde envoie votre branche main et retient la destination : les fois suivantes, git push tout court suffira. La sortie se termine par une ligne du type :

 * [new branch]      main -> main

d. Vérifiez. Rechargez la page GitHub : vos fichiers, et le nombre de commits en haut de la liste, doivent y être. La vraie vérification est un clone frais, ailleurs sur votre disque :

cd /tmp
git clone git@github.com:VOTRE-LOGIN/git-homework.git verif
cd verif && git log --oneline --graph

Vous devez y retrouver vos commits, le merge à deux parents, le Revert. Vous pouvez ensuite supprimer ce dossier : rm -rf /tmp/verif.

Si ça coince, lisez le message, il correspond presque toujours à l'un de ces cas :

Message Cause Solution
error: remote origin already exists. remote add a déjà été lancé git remote set-url origin <adresse>
Permission denied (publickey) pas de clé SSH sur cette machine revoir l'étape a, se faire aider
! [rejected] main -> main (fetch first) dépôt GitHub créé avec un README le supprimer (Settings, tout en bas, Delete this repository) et le recréer vide
error: src refspec main does not match any votre branche ne s'appelle pas main, ou aucun commit git branch pour voir son nom ; remplacer main par ce nom
Repository not found faute dans l'adresse ou le nom du dépôt git remote -v pour relire l'adresse, puis set-url

Ce que je regarderai

Rien n'est noté sur ce TP. Je passerai simplement, dans la semaine, sur les dépôts git-homework pour vérifier qu'ils existent et que l'historique ressemble à celui demandé : plusieurs commits aux messages lisibles, un .gitignore, un merge fast-forward et un rebase (tous deux invisibles, c'est normal : l'histoire est en ligne droite), un merge commit à deux parents issu d'un conflit, un Revert. Si le vôtre n'y est pas, poussez-le quand vous pourrez : c'est à la racine de ce dépôt que vous commiterez solvedMap.json pour le bonus learngitbranching, avant le mercredi 21 octobre 2026, 18 h.

Pour toute question, vous pouvez me contacter par email : raphael@imagine-app.fr.

Retour à l'accueilLe bonus learngitbranching