Sélection de révisions Git

Git offre une dizaine de syntaxes pour désigner un commit précis : SHA court, HEAD~3, main^2, HEAD@{5}, A..B. Comprendre ces syntaxes est indispensable pour utiliser efficacement log, diff, reset, rebase et cherry-pick. Ce guide couvre toutes les formes de sélection de révisions.

Prérequis : Consulter l'historique et Les branches en bref.

Ce que vous allez apprendre

• Utiliser ^ et ~ pour naviguer dans l'historique commit par commit
• Cibler des plages de commits avec les opérateurs A..B et A...B
• Retrouver un commit perdu avec HEAD@{N} et le reflog
• Résoudre n'importe quelle référence en SHA avec git rev-parse

SHA et SHA court

Chaque commit est identifié par un hash de 40 caractères, SHA-1 étant le format par défaut aujourd'hui :

a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0

En pratique, les 7 premiers caractères suffisent (SHA court) :

git show a1b2c3d
git log --oneline   # Affiche les SHA courts automatiquement

Git résout le SHA court vers le hash complet tant qu'il n'y a pas d'ambiguïté. Pour un projet très gros, utilisez 8 à 12 caractères.

Pour obtenir le SHA complet à partir d'un court :

git rev-parse a1b2c3d
# a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0

Références de branches et tags

Les noms de branches et tags sont des alias vers un SHA :

git rev-parse main        # SHA du dernier commit de main
git rev-parse v1.2.0      # SHA du commit pointé par le tag
git rev-parse HEAD         # SHA du commit courant

HEAD pointe toujours vers le commit courant (via la branche active).

Ancêtres : ^ et ~

Deux opérateurs pour naviguer vers les parents d'un commit :

L'opérateur ~ (tilde), remonter en ligne droite

~n remonte de n commits sur le premier parent :

HEAD~0 = HEAD
HEAD~1 = parent de HEAD
HEAD~2 = grand-parent de HEAD
HEAD~3 = arrière-grand-parent

git show HEAD~3    # 3 commits avant HEAD
git diff HEAD~5 HEAD   # Différences sur les 5 derniers commits

L'opérateur ^ (caret), choisir un parent

Windows : cmd.exe interprète le caret différemment

Sous Windows, cmd.exe traite ^ comme un caractère d'échappement. Les commandes git show HEAD^ ou git log HEAD^2 échouent avec une erreur.

Solutions selon le terminal utilisé :

# cmd.exe : doublez le caret
git show HEAD^^

# PowerShell : entourez de guillemets
git show "HEAD^"
git show 'HEAD^2'

# Git Bash, WSL, terminaux Unix : aucun problème
git show HEAD^

^n sélectionne le n-ième parent d'un commit de merge :

HEAD^   = HEAD^1 = premier parent (branche dans laquelle on a mergé)
HEAD^2  = deuxième parent (branche qui a été mergée)

Pour un commit normal (non-merge), ^ et ~ sont équivalents : HEAD^ = HEAD~1.

Combiner ^ et ~

HEAD~2^2   = grand-parent de HEAD, deuxième parent
HEAD^^     = HEAD~2 (parent du parent, premier parent à chaque fois)
HEAD^2~3   = 3 commits avant le deuxième parent de HEAD

Règle simple

Utilisez ~ pour « remonter de N commits ». Utilisez ^ quand vous avez un commit de merge et devez choisir quel parent suivre.

Le reflog : HEAD@{n}

Le reflog enregistre chaque position de HEAD (et des branches) dans le temps. Contrairement à l'historique (qui suit les commits), le reflog suit les mouvements :

git reflog
# a1b2c3d HEAD@{0}: commit: Ajout feature X
# e4f5a6b HEAD@{1}: checkout: moving from main to feature
# d7c8b9a HEAD@{2}: commit: Fix bug Y

Utilisation :

git show HEAD@{3}          # Position de HEAD il y a 3 mouvements
git show main@{yesterday}  # Où pointait main hier
git show HEAD@{2.hours.ago}  # HEAD il y a 2 heures
git diff HEAD@{0} HEAD@{5}   # Ce qui a changé en 5 mouvements

Durée de rétention

Le reflog est local et conservé 90 jours par défaut (30 jours pour les entrées non atteignables). Il n'est pas partagé avec git push.

Le reflog est votre filet de sécurité : même après un reset --hard, le commit précédent reste dans le reflog pendant 90 jours.

Plages de commits

Double-point A..B, commits dans B mais pas dans A

git log main..feature    # Commits dans feature, absents de main
git log origin/main..HEAD   # Commits locaux non encore poussés

Cette syntaxe est la plus courante. Elle répond à la question : « quels commits dois-je pousser ? » ou « quels commits apporte cette branche ? ».

Triple-point A...B, commits dans l'un OU l'autre, mais pas les deux

git log main...feature           # Exclusifs à main OU feature
git log --left-right main...feature   # Indique < (main) ou > (feature)

Résultat avec --left-right :

< d7c8b9a Fix bug Y             (seulement dans main)
> a1b2c3d Ajout feature X       (seulement dans feature)
> e4f5a6b Refactor module Z     (seulement dans feature)

Exclusion avec --not ou ^

git log feature --not main         # Équivalent à main..feature
git log feature ^main              # Même chose (^ en début = exclusion)
git log feature ^main ^develop     # Dans feature, ni dans main ni develop

git rev-parse : l'outil de résolution

git rev-parse traduit n'importe quelle syntaxe en SHA :

git rev-parse HEAD~3         # SHA du commit 3 avant HEAD
git rev-parse main^2         # SHA du 2e parent du dernier commit de main
git rev-parse --short HEAD   # SHA court (7 caractères)
git rev-parse --verify HEAD@{5}   # Vérifie que la ref existe

Cas pratiques en scripting :

# Vérifier qu'on est sur main
if [[ "$(git rev-parse --abbrev-ref HEAD)" != "main" ]]; then
  echo "Pas sur main !"
  exit 1
fi

# Comparer deux branches
MERGE_BASE=$(git merge-base main feature)
echo "Point de divergence : $MERGE_BASE"

Récapitulatif des syntaxes

Syntaxe	Signification	Exemple
abc1234	SHA court	git show abc1234
HEAD	Commit courant	git show HEAD
main	Dernier commit de la branche	git log main
v1.0	Commit du tag	git show v1.0
HEAD~n	N-ième ancêtre (premier parent)	git show HEAD~3
HEAD^n	N-ième parent (merge)	git show HEAD^2
HEAD@{n}	N-ième entrée reflog	git show HEAD@{5}
@{yesterday}	Reflog par date	git show main@{yesterday}
A..B	Dans B, pas dans A	git log main..feature
A...B	Exclusifs à A ou B	git log main...feature
^A / --not A	Exclure A	git log feature ^main

Glissez pour voir

Dépannage

Symptôme	Cause probable	Solution
ambiguous argument 'HEAD^' (Windows)	^ interprété par cmd.exe	Utilisez HEAD^^ ou "HEAD^" entre guillemets
fatal: bad default revision 'HEAD'	Repo vide, pas de commit	Faites un premier commit
reflog affiche (unreachable)	Commit orphelin	Normal, récupérable pendant 90 jours
SHA court ambigu	Collision de hash partiel	Utilisez plus de caractères (--abbrev=12)

Glissez pour voir

À retenir

• ~n remonte de N commits en ligne droite (premier parent)
• ^n choisit le N-ième parent d'un merge
• A..B = commits dans B absents de A (le plus utilisé)
• A...B = commits exclusifs à l'une ou l'autre branche
• Le reflog (HEAD@{n}) est votre filet de sécurité local
• git rev-parse traduit toute syntaxe en SHA

Contrôle de connaissances

Vérifiez que l'essentiel de ce guide est acquis. Les questions portent uniquement sur ce qui vient d'être expliqué ici.

Contrôle de connaissances

Validez vos connaissances avec ce quiz interactif

10 questions

6 min.

70% requis

Informations

• Le chronomètre démarre au clic sur Démarrer
• Questions à choix multiples, vrai/faux et réponses courtes
• Vous pouvez naviguer entre les questions
• Les résultats détaillés sont affichés à la fin

Démarrer le quiz

Lance le quiz et démarre le chronomètre

Pour aller plus loin

• Git stash et git clean : mettre de côté et nettoyer : La mise de côté d'un travail en cours avant de naviguer dans les révisions.
• Rechercher dans Git : grep, log -S, log -L : La recherche de contenu qui complète la désignation de révisions.
• Debug avec git bisect et git blame : L'exploitation des plages de commits pour isoler une régression.

×

📖 Voir la documentation →