Cours Git — commits, branches, annulations sûres et dépôts distants

Objectifs d'apprentissage

À la fin de ce cours, l'apprenant peut :

1. décrire le modèle de données de Git (blobs, arbres, commits, références) et dire ce qu'est une branche ;
2. situer un fichier dans l'une des trois zones (répertoire de travail, index, dépôt) et choisir la commande qui le déplace ;
3. créer des branches, les intégrer par fusion (merge) ou par réécriture (rebase) et dire quand préférer l'un ou l'autre ;
4. résoudre un conflit de fusion, ou l'abandonner proprement ;
5. annuler une erreur sans détruire d'historique (restore, revert) et retrouver un état perdu avec reflog ;
6. relier un dépôt local à un dépôt distant en HTTPS, récupérer (fetch) et publier (push) ;
7. écrire un .gitignore, rédiger des commits lisibles ;
8. éviter de commiter un secret et savoir quoi faire si cela est arrivé ;
9. reconnaître les opérations destructives (reset --hard, push --force, clean) et les précéder d'une prévisualisation.

Prérequis

• Savoir ouvrir Terminal et lire une commande avant de la valider (cours « Terminal macOS »).
• Git installé et disponible : git --version répond. Ce cours n'enseigne pas l'installation ; la source de référence est git-scm.com (méthode d'installation sur macOS : non vérifiée ici).
• Un dossier de test jetable, vide. Les exercices n'ont besoin d'aucun droit administrateur ni d'aucun compte distant, sauf le chapitre 8 qui se lit sans exécuter.

Parcours et chapitres

1. Le modèle de données : commits, arbres, références

D'après Pro Git (chapitre « Git Objects »), Git est un système de fichiers adressable par contenu : un simple magasin clé-valeur où chaque contenu inséré reçoit une clé calculée à partir de lui (un hachage SHA-1 dans le livre). Trois types d'objets forment l'essentiel :

Un commit désigne donc une photographie complète du projet, pas une différence. Il pointe vers son ou ses parents : c'est ce chaînage qui forme l'historique. Une référence est un nom lisible qui pointe vers un commit. Une branche est, selon Pro Git, « un pointeur léger et déplaçable vers l'un de ces commits » ; à chaque nouveau commit, le pointeur de la branche courante avance. HEAD indique la branche (ou le commit) sur laquelle on se trouve ; le livre précise que, dans Git, HEAD pointe vers une branche locale plutôt que directement vers un commit.

Le livre décrit un hachage SHA-1 ; l'état actuel de la prise en charge d'autres algorithmes de hachage dans Git 2.56 n'a pas été consulté : non vérifié.

2. Les trois zones de travail

Pro Git (« Reset Demystified ») décrit trois « arbres » que Git manipule :

Les états d'un fichier suivi, selon Pro Git : non modifié, modifié, indexé (staged) ; un fichier absent du dernier instantané et de l'index est « non suivi » (untracked).

Exemple, dans un dépôt de test :

Attention, effet notable. Cette commande peut créer ou modifier une configuration, écrire ou écraser un fichier. Lire le contexte, les droits et l’effet attendu indiqués après le bloc ; ne jamais l’exécuter sur un système réel sans validation, d’abord dans un environnement de test.

git init projet-democd projet-demoecho "bonjour" > salut.txtgit statusgit add salut.txtgit statusgit diff --stagedgit commit -m "Ajoute le fichier de salutation"

• Contexte : Terminal, dossier de test jetable hors de l'Orchestrator (sinon dépôt imbriqué), Git installé (version de Stéphane inconnue).
• Droits : utilisateur normal, droit d'écriture dans le dossier.
• Effet : git init crée un dépôt (dossier caché .git) ; echo … > crée ou écrase salut.txt ; git add copie le fichier dans l'index ; git commit crée un commit. Si Git demande un nom et un courriel d'auteur (user.name, user.email), utiliser des valeurs fictives dans le dépôt de test. Le nom de la branche par défaut dépend de la configuration : non vérifié.
• Vérification : git status indique d'abord « Untracked files », puis « Changes to be committed », puis un arbre propre ; git log --oneline montre le commit.
• Retour arrière : supprimer le dossier de test entier (cd .. puis supprimer projet-demo en relisant son nom).

Pro Git précise que git diff compare le répertoire de travail à l'index, tandis que git diff --staged (ou --cached) compare l'index au dernier commit. Un fichier modifié après git add doit être ajouté à nouveau pour que la dernière version soit dans le prochain commit. git status -s donne une vue courte à deux colonnes (index, répertoire de travail).

3. Branches

Selon Pro Git, créer une branche revient à écrire un petit fichier contenant l'identifiant d'un commit : c'est quasi instantané et peu coûteux. Le livre présente git switch (disponible à partir de Git 2.23, d'après le livre) et l'ancienne forme git checkout -b.

git switch -c essaigit log --oneline --decorate --graph --allgit switch -

• Contexte : dépôt de test du chapitre 2 ; Git 2.23 ou plus pour switch (version de Stéphane : non vérifié).
• Droits : utilisateur normal.
• Effet : -c essai crée la branche essai et s'y place ; git log … --decorate --graph --all affiche les pointeurs de branches et la forme de l'historique (lecture seule) ; git switch - revient à la branche précédente. Le changement de branche modifie les fichiers du répertoire de travail ; s'il y a des modifications non commitées qui gênent, Git refuse (détail du refus : non vérifié dans les pages consultées).
• Vérification : git branch marque la branche courante d'une étoile ; git status indique « On branch … ».
• Retour arrière : revenir sur l'autre branche, puis git branch -d essai (supprime la branche si elle est fusionnée ; le livre l'utilise après une fusion).

4. Intégrer des branches : merge ou rebase

Fusion (merge). D'après la documentation de git merge : si la branche courante est un ancêtre de la branche fusionnée, Git avance simplement le pointeur (fast-forward, aucun commit créé). Si les deux ont divergé, Git crée un commit de fusion à deux parents. --no-ff force ce commit de fusion même si l'avance rapide était possible ; --ff-only refuse la fusion si l'avance rapide est impossible (sortie non nulle).

Réécriture (rebase). git rebase rejoue une série de commits sur un autre point de départ : l'historique devient linéaire, mais les commits rejoués sont de nouveaux commits (identifiants différents). Pro Git expose deux philosophies : l'historique comme enregistrement fidèle (on garde les fusions) ou comme récit (on le nettoie avant de le publier). Les deux donnent le même instantané final.

git switch maingit merge --no-ff essai

• Contexte : dépôt de test où essai a au moins un commit ; remplacer main par le nom réel de la branche principale du dépôt de test.
• Droits : utilisateur normal.
• Effet : crée un commit de fusion (ou s'arrête sur un conflit, chapitre 5). Ne touche à aucun dépôt distant.
• Vérification : git log --oneline --graph montre les deux lignes qui se rejoignent.
• Retour arrière : avant tout autre commit, git reset --hard ORIG_HEAD (destructif pour le travail non commité ; voir chapitre 11) ; ORIG_HEAD après une fusion : non vérifié dans les pages consultées, vérifier avec git help merge. Pour une fusion en cours : git merge --abort.

Pour rebase :

git switch essaigit rebase main

• Contexte : dépôt de test, branche essai jamais poussée.
• Droits : utilisateur normal.
• Effet : réécrit les commits de essai ; en cas de conflit, la reprise s'arrête sur le commit gênant.
• Vérification : git log --oneline --graph montre une ligne droite ; git status ne signale plus de rebase en cours.
• Retour arrière : pendant le rebase, git rebase --abort. Après coup, l'ancien sommet reste accessible par le reflog de la branche (@{1}, d'après la documentation de git rebase) ; voir chapitre 7.

5. Résoudre un conflit

Quand deux branches modifient les mêmes lignes, git merge s'arrête avec un message du type « CONFLICT (content) » et laisse des marqueurs dans le fichier (Pro Git, git merge) :

<<<<<<< HEAD
version de la branche courante
=======
version de la branche fusionnée
>>>>>>> essai

Entre <<<<<<< et ======= : votre côté (HEAD). Entre ======= et >>>>>>> : l'autre côté. Le réglage merge.conflictStyle (diff3, zdiff3) ajoute la version d'origine, ce qui aide à comprendre un conflit.

Procédure, d'après Pro Git et la documentation de git merge :

1. git status liste les « Unmerged paths » ;
2. éditer chaque fichier : garder la bonne version, supprimer les trois lignes de marqueurs ;
3. git add <fichier> pour déclarer le conflit résolu ;
4. git commit ou git merge --continue pour conclure ;
5. pour renoncer : git merge --abort (peut échouer si des modifications non commitées chevauchent les fichiers fusionnés).

git mergetool ouvre un outil visuel configuré ; son choix n'est pas couvert ici.

6. Annuler sans détruire : restore, revert

Pro Git est explicite sur git restore <fichier> : c'est « une commande dangereuse » ; les modifications locales sont perdues, et ce qui n'a jamais été commité n'est probablement jamais récupérable. Elle n'est donc à utiliser que si l'on est certain de ne plus vouloir ces modifications. À l'inverse, git revert n'efface rien : il ajoute un commit d'inversion, ce qui convient à une branche partagée. Pour annuler un commit de fusion, il faut préciser le parent de référence avec -m <numéro> (en partant de 1) ; la documentation avertit qu'annuler une fusion revient à déclarer qu'on ne veut plus jamais les changements apportés par cette fusion.

git commit --amend : Pro Git recommande de n'amender que des commits locaux, pas encore poussés.

Attention, effet notable. Cette commande peut écraser des données par une restauration. Lire le contexte, les droits et l’effet attendu indiqués après le bloc ; ne jamais l’exécuter sur un système réel sans validation, d’abord dans un environnement de test.

git restore --staged salut.txtgit revert --no-edit HEAD

• Contexte : dépôt de test avec au moins deux commits ; --no-edit (accepte le message proposé) : option usuelle, non vérifiée dans les pages consultées.
• Droits : utilisateur normal.
• Effet : la première ligne sort salut.txt de l'index sans toucher au fichier ; la seconde crée un commit qui inverse le dernier commit.
• Vérification : git status, puis git log --oneline montrent le nouveau commit d'inversion et l'historique intact.
• Retour arrière : pour le revert, revenir en arrière avec un second git revert du commit d'inversion.

7. Retrouver un état perdu : reflog, stash

Le reflog enregistre les déplacements des sommets de branches et de HEAD dans le dépôt local (documentation de git reflog). git reflog (ou git reflog show HEAD) les liste ; HEAD@{2} désigne l'endroit où se trouvait HEAD deux déplacements plus tôt ; master@{one.week.ago} une date relative. Par défaut, les entrées atteignables sont conservées 90 jours (gc.reflogExpire) et les entrées inatteignables 30 jours (gc.reflogExpireUnreachable), ces valeurs étant celles de la page consultée.

Ainsi, après un reset --hard ou un rebase malheureux sur des commits qui avaient été commités, le reflog permet de retrouver l'ancien sommet. Il ne rattrape pas ce qui n'a jamais été commité.

git refloggit switch -c recuperation HEAD@{1}

• Contexte : dépôt de test où un reset ou un rebase vient d'avoir lieu ; HEAD@{1} est à remplacer par l'entrée vue dans la liste.
• Droits : utilisateur normal.
• Effet : la première ligne est en lecture seule ; la seconde crée une branche recuperation au point indiqué, sans toucher à la branche actuelle.
• Vérification : git log --oneline recuperation montre les commits retrouvés.
• Retour arrière : git branch -D recuperation supprime la branche (la majuscule force la suppression ; relire le nom avant de valider).

git stash met de côté les modifications suivies (push), les liste (list) et les réapplique (pop ou apply) ; -u inclut les fichiers non suivis. Attention, d'après la documentation : drop et clear suppriment des entrées que l'on peut ne plus pouvoir récupérer, et un pop en conflit conserve l'entrée de pile.

8. Dépôts distants et HTTPS

Pro Git : le dépôt distant se nomme par un « shortname » ; origin est le nom créé par défaut à un clonage.

GitHub Docs : une URL HTTPS fonctionne partout, mais n'accepte plus un mot de passe de compte ; on fournit un jeton d'accès personnel à la place, ou on passe par un assistant d'identifiants. Pro Git décrit les assistants : cache (mémoire, 15 minutes par défaut, rien sur le disque), store (mot de passe en clair dans un fichier du dossier personnel, jamais expiré) et osxkeychain (Trousseau macOS, sur le disque mais chiffré par le système).

Attention, effet notable. Cette commande peut créer ou modifier une configuration, modifier ou publier un dépôt. Lire le contexte, les droits et l’effet attendu indiqués après le bloc ; ne jamais l’exécuter sur un système réel sans validation, d’abord dans un environnement de test.

git remote add origin https://example.com/demo/projet-demo.gitgit remote -vgit fetch origingit push --dry-run origin main

• Contexte : dépôt de test ; example.com est un hôte fictif, la commande échouera sur un réseau réel, ce qui sert l'exercice de lecture.
• Droits : utilisateur normal ; l'envoi réel demande des droits d'écriture sur le dépôt distant.
• Effet : remote add modifie la configuration locale (.git/config) ; remote -v lit ; fetch et push --dry-run contactent l'hôte, sans modifier votre historique.
• Vérification : git remote -v affiche les deux lignes (fetch) et (push).
• Retour arrière : git remote remove origin (supprime aussi les branches de suivi associées, d'après Pro Git).

9. Ignorer des fichiers : .gitignore

Un fichier .gitignore liste des motifs de fichiers que Git ne doit pas proposer à l'indexation (gitignore). Règles essentielles : une ligne # est un commentaire ; * remplace tout sauf / ; ** traverse les dossiers ; un / final ne vise que des dossiers ; un / initial ancre le motif au dossier du .gitignore ; ! ré-inclut ce qu'un motif précédent excluait. Les motifs viennent de .gitignore, de .git/info/exclude (local au dépôt) et de core.excludesFile (personnel).

Exemple synthétique :

# secrets locaux : jamais versionnés
.env
*.pem
# produits de génération
site/
__pycache__/
.venv/

git check-ignore -v <fichier> indique quel motif ignore un fichier (lecture seule).

10. Secrets : ne jamais commiter, et que faire sinon

Prévention (règle de l'Orchestrator : aucun secret en clair dans un fichier, un commit, une URL ou un log) :

• les secrets vivent dans le Trousseau ; le dépôt ne contient que le nom du secret ;
• .env, clés et certificats sont dans .gitignore avant la première création ;
• git status puis git diff --staged avant chaque commit ; un fichier de secrets n'apparaît jamais dans la liste.

Si un secret a été commité (GitHub Docs, « Removing sensitive data from a repository »), dans cet ordre :

1. Révoquer ou renouveler le secret immédiatement. C'est la première étape et elle règle souvent le risque à elle seule : un secret révoqué est inutilisable.
2. Considérer le secret comme compromis, même si le dépôt est privé et même s'il n'a pas été poussé.
3. Si le secret n'a pas été poussé et que c'est le dernier commit : git commit --amend après retrait, ou git reset --soft HEAD~ (le commit disparaît, les fichiers restent), puis recommencer sans le secret.
4. S'il a été poussé, la réécriture d'historique se fait avec un outil dédié. La documentation de git filter-branch déconseille son usage et recommande git filter-repo ; GitHub Docs indique qu'il faut la version 2.47 ou plus pour son option --sensitive-data-removal. Procédure détaillée : à lire sur la page officielle, non reprise ici car elle réécrit tout l'historique.
5. La réécriture ne suffit pas : GitHub signale que la donnée peut rester accessible dans des clones, des forks, des vues en cache par identifiant et des demandes de fusion ; les collègues doivent nettoyer leurs copies.

11. Opérations destructives : savoir les reconnaître

Détails de la documentation : git clean exige -f par défaut (clean.requireForce) ; -n n'efface rien ; deux -f sont nécessaires pour toucher un dépôt imbriqué. git push --force s'applique à toutes les références poussées ; la forme +main limite la force à une référence.

Attention, effet notable. Cette commande peut modifier ou publier un dépôt. Lire le contexte, les droits et l’effet attendu indiqués après le bloc ; ne jamais l’exécuter sur un système réel sans validation, d’abord dans un environnement de test.

git clean -n -dgit push --dry-run --force-with-lease origin main

• Contexte : dépôt de test ; les deux commandes sont des prévisualisations.
• Droits : utilisateur normal.
• Effet : la première liste ce que git clean -d supprimerait, sans rien supprimer ; la seconde simule un envoi forcé prudent. Aucun fichier ni aucune référence n'est modifié.
• Vérification : la sortie affiche « Would remove … » pour clean, et un résumé sans envoi réel pour push.
• Retour arrière : sans objet pour une simulation ; pour la version réelle de clean ou reset --hard, aucun retour arrière n'existe pour du travail non commité.

12. Bonnes pratiques de commits

La documentation de git commit recommande : une première ligne courte (50 caractères au plus) qui résume le changement, une ligne vide, puis un corps qui explique. Le texte jusqu'à la première ligne vide sert de titre dans tout Git.

• un commit = un changement cohérent, qui se comprend et s'annule seul (revert devient simple) ;
• indexer volontairement (git add <fichier>) plutôt que git add . aveugle ; relire git diff --staged ;
• ne pas commiter de produits de génération, de secrets, de gros fichiers binaires inutiles ;
• messages en français dans les dépôts de l'Orchestrator (règle du projet), avec le pourquoi plus que le comment ;
• amender ou rebaser seulement ce qui n'a pas été poussé ;
• ne jamais pousser main avec --force ; fusion ou revert à la place.

Exercices et vérifications de fin de cours

Tous dans un dépôt de test jetable, sans distant réel.

1. Zones. Créer un fichier, le suivre dans git status à chaque étape (non suivi, indexé, commité) et dire dans quelle zone il se trouve.
2. Branche et fusion. Créer essai, y faire un commit, revenir sur la branche principale, fusionner avec --no-ff, lire git log --graph.
3. Conflit. Modifier la même ligne sur deux branches, fusionner, repérer les marqueurs, résoudre, conclure ; refaire en abandonnant avec git merge --abort.
4. Annuler. Indexer par erreur un fichier puis l'en sortir ; commiter une erreur puis la corriger avec revert.
5. Reflog. Provoquer un reset sur un dépôt de test, lire git reflog et recréer une branche à l'ancien sommet.
6. Distant fictif. Déclarer origin sur example.com, lire git remote -v, lancer git push --dry-run.
7. Ignorer. Créer .env fictif vide, l'ajouter au .gitignore, vérifier avec git status puis git check-ignore -v .env.
8. Classement. Classer les commandes du cours selon leur effet : lecture, création, modification d'historique, suppression non récupérable.
9. Plan d'urgence. Rédiger, sans exécuter, la liste des étapes à suivre si un jeton (fictif) est commité, dans l'ordre du chapitre 10.

Critères de réussite

• Distinguer blob, arbre, commit et référence, et dire ce qu'est une branche.
• Nommer la zone concernée par git add, git commit, git restore et git restore --staged.
• Expliquer pourquoi on ne rebase pas une branche déjà poussée et utilisée par d'autres.
• Résoudre ou abandonner un conflit sans laisser de marqueurs.
• Dire pourquoi restore <fichier>, reset --hard et clean -f sont irréversibles pour du travail non commité.
• Expliquer pourquoi la révocation d'un secret passe avant toute réécriture d'historique.
• Citer le périmètre des sources (documentation en ligne, Git 2.56.0 affichée le 17 octobre 2026) sans la confondre avec la version installée.