Vocabulaire Git : les termes essentiels

Quand Git affiche “HEAD detached”, “hunk” ou “upstream tracking”, la plupart des débutants ne savent pas exactement ce que cela signifie — et les guides supposent souvent que vous le savez déjà. Cette page couvre 40 termes du vocabulaire Git avec une définition précise, une analogie et un exemple. Gardez-la comme référence : les autres guides du site y renvoient directement sur les termes concernés.

Ce que vous allez trouver

Cette page est organisée par domaine :

• Objets internes : comment Git stocke réellement vos données (blob, tree, SHA, packfile)
• Les trois zones : les états de vos fichiers entre édition et commit
• Les pointeurs : HEAD, branches, refs, ORIG_HEAD
• Index et diffs : hunk, patch, stash, reflog
• Synchronisation : remote, upstream, fetch, refspec
• Manipulation de l’historique : rebase, cherry-pick, squash, reset, bisect
• Collaboration : fork, pull request, submodules, hooks, bare repository

Mode d'emploi

Utilisez Ctrl+F pour chercher un terme directement. Chaque terme est accessible par son ancre — les guides du site font des liens directs vers les définitions. Exemple : un guide sur le staging link #hunk pour vous amener ici.

---

Les objets internes Git

Git ne stocke pas des fichiers ni des diffs. Il stocke des objets immuables dans une base de données locale (le dossier .git/objects/). Tout ce que Git connaît est l’un de ces quatre types d’objets.

Blob

Un blob (Binary Large OBject) est l’objet qui stocke le contenu brut d’un fichier. Pas son nom, pas ses permissions — uniquement les octets du fichier. Deux fichiers identiques dans deux dossiers différents partagent le même objet blob. C’est une déduplication automatique et transparente.

# Voir le contenu d'un blob (contenu du fichier README.md au commit HEAD)
git cat-file -p HEAD:README.md

# Voir le type d'un objet Git
git cat-file -t abc1234
# blob

Conséquence pratique

Renommer un fichier ne crée pas un nouveau blob. Git stocke le contenu (blob) et le nom (dans l’objet tree) séparément. C’est pourquoi git log --follow peut retrouver l’historique d’un fichier malgré un renommage.

Tree

Un tree est l’objet qui représente un répertoire. Il contient une liste d’entrées : chaque entrée pointe vers un blob (fichier) ou un autre tree (sous-dossier), avec le nom et les permissions.

Un commit pointe vers un tree racine, qui pointe vers tous les blobs et sous-trees du projet. C’est cette structure arborescente qui constitue le “snapshot” complet du projet à un instant T.

# Voir le contenu du tree racine du dernier commit
git cat-file -p HEAD^{tree}
# 100644 blob a8f1b3... README.md
# 100644 blob 9c2d4a... package.json
# 040000 tree 3f2c1e... src

Commit

Un objet commit est le snapshot de votre projet à un instant précis. Il contient : une référence vers le tree racine, une ou plusieurs références vers ses commits parents, les métadonnées (auteur, date, message), et son propre SHA.

Un commit ne stocke pas un diff : il pointe vers le tree complet. Cela permet à Git de reconstruire l’état intégral du projet à n’importe quel moment sans rejouer tous les diffs depuis le début.

# Voir le contenu interne d'un commit
git cat-file -p HEAD
# tree    3f2c1e8a04b6...
# parent  abc12345def6...
# author  Jean Dupont <jean@example.com> 1711234567 +0100
# committer Jean Dupont <jean@example.com> 1711234567 +0100
#
# Ajout de la page d'accueil

Tag

Un tag (étiquette) marque un commit spécifique, généralement une version publiée. Il en existe deux types :

Type	Commande	Objet distinct	Recommandé pour
Léger	git tag v1.0	Non	Marquage rapide local
Annoté	git tag -a v1.0 -m "Version 1.0"	Oui (avec SHA propre)	Releases officielles

Glissez pour voir

Les tags annotés sont recommandés pour les releases : ils ont leur propre SHA, contiennent un message, une date de création et un auteur distincts. Ils peuvent être signés GPG (-s) et apparaissent dans git describe.

# Créer un tag annoté
git tag -a v2.1.0 -m "Release 2.1.0 : support multi-tenant"

# Lister les tags
git tag -l "v2.*"

# Voir le détail d'un tag annoté
git show v2.1.0

SHA et hash

Le SHA est l’identifiant unique de chaque objet Git. C’est un hash SHA-1 de 40 caractères hexadécimaux, calculé à partir du contenu complet de l’objet. Le moindre changement (un octet) donne un SHA entièrement différent.

# SHA complet du commit courant
git rev-parse HEAD
# e4a1c0f3d8b2a7f19c05d3e6b4a8f2c0e1d5b9a3

# SHA abrégé (7 caractères, suffisant en pratique)
git rev-parse --short HEAD
# e4a1c0f

Vous n’avez pas besoin des 40 caractères. Git accepte tout préfixe non ambigu, en général 7 à 8 caractères suffisent. Si deux objets partagent le même préfixe, Git vous demande d’allonger.

Le SHA remplit deux rôles : il identifie l’objet ET garantit son intégrité. Si un objet est corrompu ou altéré lors d’un transfert, son SHA recalculé ne correspond plus — Git détecte l’erreur.

Packfile

Un packfile est un format de stockage optimisé qui regroupe plusieurs objets Git en un seul fichier compressé. Git commence par stocker chaque objet séparément dans .git/objects/, puis les regroupe périodiquement dans un packfile pour économiser l’espace disque.

# Déclencher manuellement la création d'un packfile
git gc

# Voir les packfiles
ls -lh .git/objects/pack/
# total 48M
# -rw-r--r-- 1 bob bob  48M mars  28 10:42 pack-abc123.pack
# -rw-r--r-- 1 bob bob 512K mars  28 10:42 pack-abc123.idx

Les packfiles utilisent une compression par delta en interne : au lieu de stocker chaque version d’un fichier entièrement, Git peut stocker certains objets comme “objet de base + delta de modifications”. C’est un détail d’implémentation transparent pour l’utilisateur.

Delta

Un delta est la représentation d’un objet Git comme la différence par rapport à un autre objet de base, utilisé à l’intérieur des packfiles pour économiser l’espace.

Ne pas confondre snapshots et deltas

Le modèle conceptuel de Git est basé sur les snapshots (pas les deltas). Les deltas ne sont qu’un détail d’optimisation du stockage interne. Quand vous faites git diff, Git reconstruit les deux snapshots complets et calcule la différence à la volée.

---

Les zones de travail

Git gère vos fichiers à travers trois zones distinctes. Comprendre ces zones est la clé pour démystifier la quasi-totalité des commandes Git.

Working directory

Le working directory (répertoire de travail) est le dossier de votre projet tel que vous le voyez et l’éditez dans votre éditeur ou terminal. C’est là que vivent vos fichiers réels. Git surveille les différences entre le working directory et son index (staging area).

État d’un fichier	Signification
Untracked	Git ne connaît pas encore ce fichier
Modified	Modifié depuis le dernier commit, non stagé
Staged	Ajouté à la staging area, prêt pour le commit
Committed	Enregistré dans le repository

Glissez pour voir

# Voir l'état de votre working directory
git status

# Version courte
git status -s
# M  fichier.js   ← colonne gauche = staged, colonne droite = not staged
#  M autre.js
# ?? nouveau.js   ← untracked

Staging area

La staging area (aussi appelée index) est la zone intermédiaire entre le working directory et le repository. Elle contient l’état exact de ce que sera votre prochain commit. git add y déplace des fichiers ou des parties de fichiers ; git commit transforme son contenu en un commit permanent.

Working directory  →(git add)→  Staging area  →(git commit)→  Repository

L’analogie classique : la staging area est votre panier de courses. Vous ajoutez des articles (fichiers modifiés) que vous validez (commitez) en passant en caisse.

Pourquoi cet intermédiaire ? Il vous permet de ne committer qu’une partie de vos modifications. Si vous avez modifié 10 fichiers, vous pouvez créer deux commits propres en staging 5 fichiers à la fois.

# Voir ce qui est dans la staging area (différence avec dernier commit)
git diff --staged

# Retirer un fichier de la staging area (sans toucher au working dir)
git restore --staged fichier.js

# Voir l'index en détail
git ls-files --stage

Alias : Index

Git utilise souvent le terme Index dans son code interne et ses messages d’erreur pour désigner la staging area. Les deux termes sont synonymes exacts. Dans les messages Git, “indexed” signifie “stagé”.

Repository

Le repository (dépôt) est la base de données Git qui stocke l’intégral de l’historique de votre projet. Il est contenu dans le dossier .git/ à la racine de votre projet. Il contient tous les objets (blobs, trees, commits, tags), toutes les branches, tous les tags et la configuration locale.

# Le dossier .git contient toute la base de données
ls .git/
# COMMIT_EDITMSG  HEAD  config  hooks/  index  objects/  refs/

# Voir la taille du repository
du -sh .git/

Attention

Supprimer le dossier .git/ détruit tout l’historique Git du projet. Vos fichiers source restent intacts (ils sont dans le working directory), mais tout l’historique des commits disparaît.

---

Les pointeurs et références

HEAD

HEAD est le pointeur qui indique où vous êtes placé dans Git. Dans la majorité des cas, HEAD pointe vers la branche active (par exemple main), qui elle-même pointe vers le dernier commit de cette branche. Quand vous commitez, HEAD (et donc la branche) avancent automatiquement.

HEAD → main → commit e4a1c0f → commit parent → ...

refs/heads/main

# Voir ce que pointe HEAD
cat .git/HEAD
# Voir le SHA du commit pointé par HEAD
git rev-parse HEAD

# Utilisation dans les commandes
git show HEAD         # dernier commit
git show HEAD~1       # un commit avant
git show HEAD~2       # deux commits avant
git diff HEAD~1 HEAD  # différence entre les deux derniers commits

Syntaxe tilde et caret

• HEAD~N : N commits en remontant la lignée principale
• HEAD^ : le premier parent (équivalent à HEAD~1)
• HEAD^2 : le deuxième parent (utile après un merge)
• HEAD@{N} : l’état de HEAD il y a N opérations (utilise le reflog)

Detached HEAD

L’état “HEAD détaché” signifie que HEAD pointe directement sur un commit, pas sur une branche. En temps normal, HEAD pointe sur une branche qui pointe sur un commit. En HEAD détaché, HEAD saute par-dessus la branche et pointe directement sur un SHA.

Normal  :  HEAD → main → e4a1c0f
Détaché :  HEAD → e4a1c0f  (pas de branche intermédiaire)

Quand cela arrive : git checkout <sha>, git checkout <tag>, pendant l’exécution de git rebase.

Le risque : tout commit créé en HEAD détaché n’appartient à aucune branche. Si vous vous déplacez ailleurs sans créer de branche, ces commits deviennent orphelins et seront supprimés par git gc après 30 jours.

# Git vous avertit
git checkout abc1234
# HEAD is now at abc1234 Mon commit
# You are in 'detached HEAD' state.

# Solution : créer une branche pour sauvegarder le travail
git switch -c branche-de-sauvegarde

→ Guide dédié : HEAD détaché : naviguer sans branche

Ref

Une ref (référence) est tout nom symbolique qui pointe vers un objet Git — généralement un commit. Les branches, les tags, HEAD et les références spéciales sont tous des refs. Git les stocke dans .git/refs/ sous forme de fichiers texte.

Type de ref	Exemples	Emplacement dans .git/
Branche locale	main, feature/login	refs/heads/
Branche distante	origin/main	refs/remotes/
Tag	v1.0, v2.0-rc1	refs/tags/
HEAD	Position actuelle	HEAD
Spéciaux	ORIG_HEAD, MERGE_HEAD	racine de .git/

Glissez pour voir

# Voir toutes les refs du dépôt
git show-ref

# Résoudre le SHA d'une ref
git rev-parse refs/heads/main

ORIG_HEAD, MERGE_HEAD, FETCH_HEAD

Git crée des références temporaires pour sauvegarder des états importants. Elles disparaissent une fois l’opération terminée.

ORIG_HEAD : Git sauvegarde l’ancien HEAD ici avant toute opération risquée (merge, rebase, reset). Cela vous permet de revenir à l’état précédent avec une seule commande.

# Avant : git rebase main (qui a mal tourné)
git reset --hard ORIG_HEAD  # retour à l'état d'avant

MERGE_HEAD : présent pendant un merge avec conflits. Git y stocke le SHA de la branche en cours de fusion. Disparaît après git commit ou git merge --abort.

FETCH_HEAD : contient le SHA de la branche distante récupérée par le dernier git fetch. git pull utilise FETCH_HEAD pour savoir quoi merger après le fetch.

# Voir le contenu après un fetch
cat .git/FETCH_HEAD
# abc1234  branch 'main' of https://github.com/user/projet.git

---

Index et modifications

Hunk

Un hunk est un bloc contigu de lignes modifiées dans un diff. Un fichier modifié peut contenir plusieurs hunks, séparés par des lignes non modifiées. Git utilise ce découpage pour vous permettre de stager ou ignorer des modifications ligne par ligne — et non fichier par fichier.

@@ -15,7 +15,9 @@ def calculate():
     result = 0
-    for i in range(10):
+    for i in range(100):
+        if i % 2 == 0:
+            continue
     result += i
     return result

L’en-tête @@ -15,7 +15,9 @@ se lit : “dans l’original, ce bloc commence à la ligne 15 sur 7 lignes ; dans la nouvelle version, il commence à la ligne 15 sur 9 lignes”.

Quand vous faites git add -p, Git vous présente les hunks un à un et vous demande pour chacun : stager (y), ignorer (n), découper en plus petits (s) ou éditer manuellement (e).

# Stager hunk par hunk
git add -p

# Options principales du prompt
# y = yes (stager ce hunk)
# n = no (ignorer ce hunk)
# s = split (découper en hunks plus petits)
# e = edit (éditer manuellement les lignes à stager)
# q = quit

→ Guide dédié : Staging interactif

Patch

Un patch est un fichier texte qui contient un ou plusieurs hunks, avec les métadonnées nécessaires pour les appliquer à un autre code. C’est le format d’échange traditionnel dans les workflows open source (kernel Linux notamment).

# Créer un fichier patch pour le dernier commit
git format-patch HEAD~1
# 0001-Mon-commit.patch

# Appliquer un patch
git apply 0001-Mon-commit.patch

# Appliquer un patch avec les métadonnées de commit (auteur, date)
git am 0001-Mon-commit.patch

Stash

Le stash est une pile temporaire où Git sauvegarde vos modifications non commitées. git stash enregistre l’état du working directory et de la staging area, puis remet tout dans l’état du dernier commit. git stash pop réapplique les modifications sauvegardées.

Working directory modifié
        ↓ git stash
Working directory propre   +   stash contient vos modifs
        ↓ git stash pop
Working directory modifié (restauré)

# Mettre de côté vos modifications
git stash

# Voir la liste des stashs (pile LIFO)
git stash list
# stash@{0}: WIP on main: e4a1c0f Ajout login
# stash@{1}: WIP on feature: abc1234 En cours

# Récupérer le dernier stash
git stash pop

# Nommer un stash (plus lisible)
git stash push -m "feature login - formulaire incomplet"

# Stasher aussi les fichiers untracked
git stash -u

# Récupérer un stash spécifique sans le supprimer
git stash apply stash@{1}

Stash ≠ commit

Le stash est purement local à votre machine. Il ne se synchronise pas avec git push. C’est un outil de confort personnel pour changer de contexte rapidement.

→ Guide dédié : Git stash et git clean

Reflog

Le reflog (reference log) est le journal de tous les mouvements de HEAD et des branches dans votre dépôt local. Chaque fois que HEAD change — commit, checkout, merge, rebase, reset — Git enregistre une entrée dans le reflog. Il est conservé 90 jours par défaut.

C’est votre filet de sécurité ultime. Un commit “perdu” après un reset --hard ? Un commit créé en detached HEAD et abandonné ? Tout est dans le reflog tant que le délai n’est pas expiré.

# Voir le reflog de HEAD
git reflog
# e4a1c0f HEAD@{0}: commit: Ajout de la page d'accueil
# 3f2c1b0 HEAD@{1}: checkout: moving from feature to main
# abc1234 HEAD@{2}: reset: moving to HEAD~1
# def5678 HEAD@{3}: commit: Feature login

# Récupérer un commit "perdu" (remonter dans le temps)
git checkout abc1234          # naviguer vers le commit perdu
git switch -c branche-rescue  # le sauvegarder dans une branche

Reflog = local uniquement

Le reflog n’est pas partagé avec git push. Si vous clonez un dépôt, son reflog est vide. C’est votre historique de navigation personnel — il n’existe que sur votre machine.

→ Guide dédié : Récupérer des données perdues

---

Synchronisation distante

Remote

Un remote est un dépôt Git hébergé ailleurs — sur GitHub, GitLab, un serveur interne, ou même un autre dossier de votre machine. Dans votre dépôt local, un remote est une référence nommée vers l’URL de ce dépôt distant. Vous pouvez en avoir plusieurs dans un même projet.

# Voir les remotes configurés
git remote -v
# origin  https://github.com/user/projet.git (fetch)
# origin  https://github.com/user/projet.git (push)

# Ajouter un remote
git remote add backup https://gitlab.com/user/projet.git

# Renommer un remote
git remote rename origin ancien-origin

# Supprimer un remote
git remote remove backup

Origin

Origin est le nom conventionnel du remote principal — typiquement le dépôt depuis lequel vous avez cloné. Ce nom n’est pas obligatoire : c’est une convention suivie par Git et tous les outils. git clone le crée automatiquement. Vous pouvez le renommer ou en utiliser un autre.

# Origin est créé automatiquement par git clone
git clone https://github.com/user/projet.git
cd projet
git remote -v
# origin  https://github.com/user/projet.git (fetch)
# origin  https://github.com/user/projet.git (push)

Upstream

Le terme “upstream” a deux significations selon le contexte :

1. La branche distante suivie par une branche locale. Quand vous faites git push -u origin main, vous configurez origin/main comme l’upstream de votre main local. Cela permet ensuite d’utiliser git push et git pull sans arguments.

# Configurer l'upstream d'une branche
git push -u origin feature/login

# Voir l'upstream configuré de chaque branche locale
git branch -vv
# * main      e4a1c0f [origin/main] Mon commit
#   feature   abc1234 [origin/feature: ahead 2] Ma feature
# "ahead 2" = 2 commits locaux non encore poussés
# "behind 3" = 3 commits distants non encore récupérés

2. Le dépôt original dans un workflow de fork. Si vous forkez un projet sur GitHub, le dépôt original s’appelle conventionnellement “upstream” et votre fork s’appelle “origin”.

# Configuration fork classique
git remote add upstream https://github.com/projet-original/projet.git
git remote add origin   https://github.com/votre-fork/projet.git

# Récupérer les mises à jour de l'original
git fetch upstream
git merge upstream/main

Tracking branch

Une tracking branch (branche de suivi) est une branche locale configurée pour suivre une branche distante. Elle sait automatiquement où git push doit envoyer et où git pull doit récupérer.

# Créer une branche locale qui suit une branche distante
git switch --track origin/feature-xyz
# Branch 'feature-xyz' set up to track remote branch 'feature-xyz' from 'origin'.

# Voir toutes les branches et leur tracking
git branch -vv

Fetch

git fetch télécharge les nouvelles données depuis le remote sans modifier votre working directory ni vos branches locales. Il met à jour les références distantes (origin/main, etc.) mais ne touche pas votre main local. git pull est essentiellement git fetch + git merge.

Avant fetch : origin/main désynchronisé avec le serveur
              ↓ git fetch
Après fetch : origin/main = état actuel du serveur
              main locale = inchangée (vous décidez quand fusionner)

# Télécharger sans fusionner
git fetch origin

# Voir ce qui a changé en amont avant de décider
git log HEAD..origin/main --oneline

# Puis fusionner manuellement
git merge origin/main
# (ou : git pull = fetch + merge en une commande)

Astuce

Préférez git fetch + git log HEAD..origin/main avant de décider de merger ou rebaser. git pull fait les deux d’un coup et peut vous surprendre si des commits distants modifient les mêmes fichiers.

Refspec

Une refspec est la syntaxe qui définit quelles références transférer entre le dépôt local et le remote. Format : [+]<src>:<dst>. Elle apparaît dans la configuration .git/config et dans les commandes git fetch et git push.

# Refspec standard créée par git clone (dans .git/config)
# fetch = +refs/heads/*:refs/remotes/origin/*
# Signifie : récupère toutes les branches du remote (refs/heads/*)
#            et stocke-les en local sous refs/remotes/origin/*

# Pousser une branche locale vers un nom différent sur le remote
git push origin feature:feature-v2

# Supprimer une branche distante (source vide)
git push origin :ancienne-branche
# équivalent :
git push origin --delete ancienne-branche

Note

Le + au début d’une refspec autorise une mise à jour non-fast-forward (force update). C’est ce que fait git push --force : il ajoute + à la refspec.

---

Manipulation de l’historique

Fast-forward

Un fast-forward est un type de merge où Git avance simplement le pointeur de branche sans créer de commit de fusion. Il est possible uniquement quand la branche à intégrer est directement en avance sur la branche cible, sans divergence — autrement dit, tous les commits de la cible sont déjà ancêtres de la branche source.

Avant fast-forward :
  main ──────► A ──► B
                         \
  feature ─────────────► C ──► D

git merge feature (depuis main)

Après fast-forward :
  main ──────────────────────────► C ──► D
  (main a juste "avancé" jusqu'à D, sans commit de merge)

# Merger en fast-forward (comportement par défaut si possible)
git merge feature

# Forcer un commit de merge même si fast-forward est possible
git merge --no-ff feature

# Refuser si le fast-forward n'est pas possible
git merge --ff-only feature

--no-ff en équipe

Dans un workflow d’équipe, --no-ff préserve dans l’historique que la feature a existé comme branche séparée (avec un commit de merge). Sans --no-ff, l’historique est plus linéaire mais moins informatif.

→ Guide dédié : Merge et conflits

Rebase

git rebase rejoue vos commits sur une nouvelle base. Au lieu de créer un commit de merge, il déplace (en les recréant avec de nouveaux SHA) vos commits comme s’ils avaient été créés après les commits de la branche cible.

Avant rebase :
  main    ──► A ──► B ──► C
  feature ──► A ──► D ──► E

git rebase main (depuis feature)

Après rebase :
  main    ──► A ──► B ──► C
  feature ──────────────────► D' ──► E'
  (D' et E' sont des nouvelles versions de D et E, avec nouveaux SHA)

# Rebaser la branche actuelle sur main
git rebase main

# Rebase interactif : réordonner, squash, modifier des commits
git rebase -i HEAD~5

# Annuler un rebase en cours
git rebase --abort

# Continuer après résolution d'un conflit
git rebase --continue

Règle d'or du rebase

Ne jamais rebaser des commits déjà poussés sur une branche partagée. Le rebase recrée les commits avec de nouveaux SHA. Si d’autres personnes ont basé leur travail sur les anciens SHA, leurs historiques divergent et la synchronisation devient complexe.

→ Guide dédié : Rebase fondamental

Cherry-pick

git cherry-pick copie un commit spécifique et l’applique sur la branche actuelle. Il recrée le commit avec un nouveau SHA (le contexte étant différent). Utile pour des backports (porter un fix sur une branche de maintenance) ou des hotfixes ciblés.

main    ──► A ──► B ──► C ──► D
feature ──► A ──► X ──► Y

git cherry-pick D (depuis feature)

feature ──► A ──► X ──► Y ──► D'
(D' est une copie de D avec un nouveau SHA)

# Appliquer un commit spécifique sur la branche actuelle
git cherry-pick abc1234

# Appliquer une plage de commits
git cherry-pick abc1234..def5678

# Cherry-pick sans créer de commit (résoudre manuellement)
git cherry-pick --no-commit abc1234

→ Guide dédié : Cherry-pick

Squash

Squasher des commits signifie les combiner en un seul commit. C’est une opération de git rebase -i : vous sélectionnez plusieurs commits et les fusionnez en un commit unique avec un message combiné ou nouveau. Utile pour nettoyer une série de commits “WIP” avant de merger.

Avant squash :
  A ──► B ──► C ──► D  (B, C, D sont des "WIP: en cours")

git rebase -i HEAD~3  (avec squash sur C et D)

Après squash :
  A ──► E  (E est un commit propre qui combine B+C+D)

# Ouvrir l'éditeur pour les 3 derniers commits
git rebase -i HEAD~3

# Dans l'éditeur, changer "pick" en "squash" ou "s"
# pick   abc1234 Feature principale
# squash def5678 WIP: ajout test
# squash ghi9012 WIP: fix lint

squash vs fixup

fixup est comme squash mais supprime le message du commit absorbé. Utile pour les commits “typo fix” ou “fix lint” que vous voulez intégrer silencieusement dans le commit précédent.

→ Guide dédié : Réécrire l’historique

Revert

git revert annule un commit en créant un nouveau commit qui applique l’inverse des modifications. Contrairement à reset, il ne modifie pas l’historique existant — il y ajoute un commit d’annulation. C’est la méthode sûre pour annuler sur une branche partagée.

# Annuler le dernier commit (crée un nouveau commit d'annulation)
git revert HEAD

# Annuler un commit spécifique dans l'historique
git revert abc1234

# Préparer le revert sans créer le commit tout de suite
git revert --no-commit abc1234
git revert --no-commit def5678
git commit -m "Annulation des features X et Y"

Reset

git reset déplace le pointeur HEAD (et optionnellement la branche) vers un commit précédent. Il a trois modes qui diffèrent par leur impact sur la staging area et le working directory :

Mode	Commande	Staging area	Working directory
Soft	git reset --soft HEAD~1	Préservée	Préservé
Mixed (défaut)	git reset HEAD~1	Vidée	Préservé
Hard	git reset --hard HEAD~1	Vidée	Réinitialisé

Glissez pour voir

# Annuler le dernier commit en gardant les modifs dans la staging area
git reset --soft HEAD~1

# Annuler le dernier commit en remettant les modifs en working directory
git reset HEAD~1

# Annuler et ABANDONNER toutes les modifications (irréversible sans reflog)
git reset --hard HEAD~1

reset --hard est destructif

git reset --hard écrase les modifications du working directory. Les commits “annulés” restent récupérables via le reflog pendant 90 jours, mais les modifications non commitées du working directory sont perdues définitivement.

→ Guide dédié : Reset démystifié

Bisect

git bisect localise le commit qui a introduit un bug par recherche dichotomique. Vous lui indiquez un commit “bon” (avant le bug) et un commit “mauvais” (avec le bug). Git sélectionne le commit médian, vous le testez, le qualifiez bon ou mauvais, et ainsi de suite. En $O(\log_2 n)$ étapes, il isole le commit fautif.

Commits : A B C D E F G H I J K L
Bug introduit quelque part entre D et I.

Bisect teste H (milieu) → "mauvais"
Bisect teste F → "bon"
Bisect teste G → "mauvais"
Résultat : G est le premier commit mauvais.

# Démarrer une session bisect
git bisect start

# Qualifier le commit actuel comme mauvais
git bisect bad

# Qualifier un ancien commit connu comme bon
git bisect good v2.0

# Pour chaque commit proposé par Git : tester et répondre
git bisect good   # ou
git bisect bad

# Terminer et revenir à la branche normale
git bisect reset

# Automatiser avec un script de test (0 = bon, non-0 = mauvais)
git bisect run npm test

→ Guide dédié : Debug avec bisect et blame

---

Dépôts et collaboration

Bare repository

Un bare repository (dépôt nu) est un dépôt Git sans working directory. Il ne contient que le contenu du dossier .git/ d’un dépôt normal. C’est le type de dépôt utilisé sur les serveurs Git (GitHub, GitLab, votre serveur interne) : il reçoit les push et sert les clone, mais personne ne travaille directement dedans.

# Créer un dépôt bare (pour servir de remote)
git init --bare mon-projet.git

# Cloner en conservant le format bare
git clone --bare https://github.com/user/projet.git

Note

La convention est de nommer les bare repositories avec l’extension .git (ex. projet.git). C’est ce que vous voyez sur GitHub quand vous copiez une URL de clone qui se termine par .git.

→ Guide dédié : Héberger son serveur Git

Orphan branch

Une orphan branch (branche orpheline) est une branche sans historique commun avec le reste du dépôt. Son premier commit n’a pas de parent. Utile pour créer une branche gh-pages (documentation) ou une branche docs entièrement indépendante du code source.

# Créer une branche orpheline (sans historique)
git switch --orphan gh-pages

# La branche est vide et n'a aucun parent
git status
# On branch gh-pages
# Initial commit (no commits yet)

Worktree

git worktree permet d’avoir plusieurs working directories attachés au même dépôt en même temps. Vous pouvez travailler sur deux branches différentes dans deux dossiers distincts, sans stash, sans clone supplémentaire.

# Créer un deuxième working directory sur la branche "hotfix"
git worktree add ../projet-hotfix hotfix/urgent

# Voir tous les worktrees actifs
git worktree list
# /home/bob/projet        e4a1c0f [main]
# /home/bob/projet-hotfix abc1234 [hotfix/urgent]

# Supprimer un worktree
git worktree remove ../projet-hotfix

Fork

Un fork est une copie d’un dépôt sur une plateforme (GitHub, GitLab). Contrairement à un clone local, un fork est un dépôt distant indépendant sous votre compte. Il est utilisé dans le workflow de contribution open source : vous forkez, travaillez sur votre fork, puis proposez vos changements via une pull request vers le dépôt original.

# Après avoir forké sur GitHub, clonez votre fork
git clone https://github.com/VOTRE-COMPTE/projet.git
cd projet

# Ajoutez le dépôt original comme "upstream"
git remote add upstream https://github.com/ORIGINAL/projet.git

# Récupérer les mises à jour de l'original
git fetch upstream
git merge upstream/main

Pull Request et Merge Request

Une Pull Request (PR sur GitHub) ou Merge Request (MR sur GitLab) est une demande formelle de fusionner une branche dans une autre, avec une interface de revue de code, des commentaires, des pipelines CI/CD et une validation avant fusion. Ce n’est pas une fonctionnalité de Git lui-même — c’est une couche ajoutée par les plateformes d’hébergement.

Plateforme	Terme	Acronyme
GitHub	Pull Request	PR
GitLab	Merge Request	MR
Bitbucket	Pull Request	PR
Azure DevOps	Pull Request	PR

Glissez pour voir

→ Guide dédié : Pull requests et code review

---

Intégration avancée

Submodule

Un submodule est un dépôt Git imbriqué dans un autre dépôt Git. Le dépôt parent stocke un pointeur vers un SHA précis du sous-dépôt (pas son contenu). Utile pour référencer une bibliothèque externe en épinglant une version précise.

# Ajouter un sous-module
git submodule add https://github.com/lib/librairie.git libs/librairie

# Cloner un dépôt avec ses sous-modules
git clone --recurse-submodules https://github.com/user/projet.git

# Mettre à jour tous les sous-modules vers leur dernière version
git submodule update --remote

→ Guide dédié : Submodules Git

Subtree

git subtree intègre le contenu d’un dépôt externe directement dans un sous-dossier de votre dépôt. Contrairement aux submodules, les fichiers sont copiés et font partie de l’historique de votre dépôt. Plus simple au quotidien car les contributeurs n’ont pas besoin de commandes spéciales pour cloner.

# Ajouter un sous-projet comme subtree
git subtree add --prefix=libs/ma-lib \
  https://github.com/lib/ma-lib.git main --squash

# Mettre à jour le subtree
git subtree pull --prefix=libs/ma-lib \
  https://github.com/lib/ma-lib.git main --squash

→ Guide dédié : Git subtree

Hooks

Les hooks Git sont des scripts exécutés automatiquement lors d’événements Git spécifiques — avant un commit, après un push, avant un merge, etc. Ils sont stockés dans .git/hooks/ et sont locaux (non versionnés par défaut).

Hook	Déclencheur	Cas d’usage courants
pre-commit	Avant chaque commit	Lint, formatage, tests rapides
commit-msg	Validation du message	Format Conventional Commits
pre-push	Avant chaque push	Tests d’intégration
post-merge	Après un merge réussi	Mise à jour des dépendances
prepare-commit-msg	Ouverture de l’éditeur du commit	Pré-remplir le message

Glissez pour voir

# Créer un hook pre-commit (exemple : lancer eslint)
cat > .git/hooks/pre-commit << 'EOF'
#!/bin/sh
npm run lint
exit $?
EOF
chmod +x .git/hooks/pre-commit

Hooks partagés en équipe

Les hooks dans .git/hooks/ ne sont pas versionnés. Pour les partager en équipe, placez-les dans un dossier versionné (ex. .githooks/) et configurez : git config core.hooksPath .githooks

---

À retenir

Terme	Définition en une phrase
Blob	Contenu brut d’un fichier dans la base de données Git
Tree	Répertoire dans la base de données Git
SHA / hash	Identifiant unique de 40 caractères de chaque objet
Packfile	Format de stockage optimisé et compressé d’objets Git
Working directory	Vos fichiers tels que vous les voyez et éditez
Staging area / Index	Zone intermédiaire entre édition et commit
Repository	Base de données Git (le dossier .git/)
HEAD	Pointeur vers votre position actuelle dans l’historique
Detached HEAD	HEAD pointe sur un commit, pas sur une branche
Ref	Tout nom symbolique pointant vers un objet Git
ORIG_HEAD	Sauvegarde automatique de HEAD avant opération risquée
Hunk	Bloc contigu de lignes modifiées dans un diff
Stash	Pile temporaire de modifications non commitées
Reflog	Journal local de tous les mouvements de HEAD (90 jours)
Remote	Référence nommée vers un dépôt Git distant
Origin	Nom conventionnel du remote principal
Upstream	Branche distante suivie / dépôt original d’un fork
Fetch	Télécharger les données distantes sans fusionner
Refspec	Syntaxe src:dst pour les transferts de références
Fast-forward	Merge sans commit de fusion (avance simple du pointeur)
Rebase	Rejouer des commits sur une nouvelle base
Cherry-pick	Copier un commit spécifique sur la branche actuelle
Squash	Combiner plusieurs commits en un seul
Revert	Annuler un commit en créant un commit d’annulation
Reset	Déplacer HEAD vers un commit précédent
Bisect	Recherche dichotomique ($O(\log n)$) du commit fautif
Bare repository	Dépôt sans working directory (utilisé sur les serveurs)
Fork	Copie d’un dépôt sur une plateforme (GitHub, GitLab)
Pull Request / MR	Demande formelle de fusion avec revue de code
Submodule	Dépôt Git imbriqué dans un autre dépôt
Hooks	Scripts exécutés automatiquement lors d’événements Git

Glissez pour voir

Prochaines étapes

Le modèle Git par snapshots Approfondissez la compréhension du modèle interne : snapshots, SHA et 3 états.

Enregistrer des modifications Staging area, git add -p, git commit : les opérations du quotidien.

Récupérer des données perdues Reflog et fsck pour retrouver commits et branches perdus.

Les bases de Git Passez à la pratique : créez un dépôt et versionnez vos premiers fichiers.

×

📖 Voir la documentation →