Diagnostiquer des problèmes dans Git

Vous avez une régression en production et vous devez trouver le commit coupable ? Git offre plusieurs outils de diagnostic : git bisect effectue une recherche dichotomique dans l'historique, git blame révèle l'auteur de chaque ligne, et git log -S retrouve le commit qui a ajouté ou supprimé un mot-clé. Ce guide couvre chaque outil avec des cas concrets.

Prérequis : Consulter l'historique et Chercher dans l'historique.

Ce que vous allez apprendre

• Utiliser git bisect pour localiser un commit régressif
• Automatiser bisect avec bisect run et un script de test
• Lire git blame pour retracer l'origine d'un bug dans le code
• Chercher dans l'historique avec log -S et log -L

Quel outil pour quel problème ?

Problème	Outil	Commande clé
Bug apparu entre deux versions	git bisect	Recherche dichotomique
Qui a modifié cette ligne ?	git blame	Annotation par ligne
Quand ce mot-clé a été ajouté/supprimé ?	git log -S	Recherche pickaxe
Comment cette fonction a évolué ?	git log -L	Historique d'un intervalle
Qui a le plus contribué ?	git shortlog	Statistiques auteur

Glissez pour voir

Trouver le commit coupable avec bisect

git bisect effectue une recherche dichotomique : à chaque étape, il vous propose un commit au milieu de l'intervalle [bon...mauvais] et vous indiquez si le bug est présent ou non. En quelques étapes, il identifie le commit exact.

Bisect manuel

1. Lancez la session bisect

   git bisect start

2. Indiquez le commit actuel comme mauvais

   git bisect bad

   Git utilise HEAD par défaut. Vous pouvez spécifier un SHA : git bisect bad a1b2c3d.

3. Indiquez un commit où tout fonctionnait

   git bisect good v1.2.0

   Utilisez un tag, un SHA, ou tout identifiant de commit.

4. Testez chaque commit proposé

   Git checkout un commit au milieu et affiche le nombre d'étapes restantes :

   Bisecting: 12 revisions left to test after this (roughly 4 steps)

   Testez le comportement, puis indiquez le résultat :

   # Si le bug est présent :
   git bisect bad
   
   # Si le bug est absent :
   git bisect good

5. Git identifie le commit coupable

   Après quelques itérations :

   a1b2c3d is the first bad commit
   commit a1b2c3d
   Author: Alice <alice@example.com>
   Date: Mon Jan 15 10:30:00 2026
   
       refactor: changer le calcul de la TVA

6. Terminez la session bisect

   git bisect reset

   Cela restaure HEAD à la position d'avant le bisect.

Toujours terminer avec bisect reset

Si vous oubliez git bisect reset, vous restez en detached HEAD sur un commit intermédiaire. Aucune donnée n'est perdue, mais exécutez git bisect reset pour revenir à votre branche.

Bisect automatique avec bisect run

Si vous disposez d'un script ou d'une commande qui retourne 0 (succès) quand le bug est absent et un code non-zéro quand le bug est présent, automatisez la recherche :

git bisect start
git bisect bad HEAD
git bisect good v1.2.0
git bisect run npm test

Git exécute npm test à chaque étape et marque automatiquement le commit comme bon ou mauvais selon le code de retour.

Avec un script personnalisé :

git bisect run ./test-regression.sh

Le script doit retourner :

• 0 : le commit est bon (pas de bug)
• 1-124, 126-127 : le commit est mauvais (bug présent)
• 125 : le commit ne peut pas être testé (skip)

Exemple de script de test

#!/bin/bash
# test-regression.sh - Vérifie si le calcul de TVA est correct
make build 2>/dev/null || exit 125  # skip si la compilation échoue
result=$(./bin/app --calculate-tax 100)
if [ "$result" = "120.00" ]; then
  exit 0   # bon
else
  exit 1   # mauvais
fi

Le code 125 est un cas spécial : il demande à bisect de sauter ce commit (utile si un commit ne compile pas).

Bisect avec des termes personnalisés

Pour un bug de performance, les termes « good/bad » peuvent prêter à confusion. Utilisez des termes personnalisés :

git bisect start --term-old=fast --term-new=slow
git bisect slow HEAD
git bisect fast v1.2.0

Identifier l'auteur d'un changement avec blame

git blame annote chaque ligne d'un fichier avec le SHA du commit, la date et l'auteur :

git blame src/utils/tax.js

a1b2c3d4 (Alice  2026-01-15 10:30) const TAX_RATE = 0.20;
e4f5a6b7 (Bob    2025-12-01 14:12) function calculateTax(amount) {
a1b2c3d4 (Alice  2026-01-15 10:30)   return amount * (1 + TAX_RATE);
f1a2b3c4 (Carol  2025-11-20 09:45) }

Blame sur un intervalle de lignes

Pour cibler un bloc spécifique :

git blame -L 10,25 src/utils/tax.js

Affiche uniquement les lignes 10 à 25.

Ignorer les commits de formatage

Un commit de reformatage (ajout de trailing commas, changement d'indentation) pollue le blame. Créez un fichier .git-blame-ignore-revs listant les SHA à ignorer :

# Reformatage prettier - 2025-06-15
a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0

Configurez Git pour l'utiliser automatiquement :

git config blame.ignoreRevsFile .git-blame-ignore-revs

Tous les appels à git blame ignoreront ces commits.

Chercher dans l'historique avec log -S (pickaxe)

git log -S retrouve les commits qui ont ajouté ou supprimé un mot-clé dans le code source :

git log -S "TAX_RATE" --oneline

a1b2c3d refactor: changer le calcul de la TVA
f1a2b3c feat: ajouter le calcul de taxe

Cela montre les commits où TAX_RATE est apparu ou disparu du diff.

Recherche par expression régulière

Pour une recherche plus flexible :

git log -G "TAX_RATE\s*=\s*0\.\d+" --oneline

-G utilise une expression régulière au lieu d'une chaîne littérale.

Limiter à un fichier

git log -S "TAX_RATE" -- src/utils/tax.js

L'opérateur -- sépare les options des chemins de fichiers.

Suivre l'évolution d'une fonction avec log -L

git log -L affiche l'historique des modifications d'un intervalle de lignes ou d'une fonction :

Par nom de fonction

git log -L :calculateTax:src/utils/tax.js

Git identifie automatiquement les bornes de la fonction calculateTax et montre chaque commit qui l'a modifiée, avec le diff correspondant.

Par intervalle de lignes

git log -L 10,25:src/utils/tax.js

Affiche l'historique des modifications entre les lignes 10 et 25.

Détection des fonctions

La détection automatique des fonctions repose sur les patterns du langage configurés dans .gitattributes. Pour la plupart des langages courants (JS, Python, C, Java), Git les détecte sans configuration supplémentaire.

Statistiques avec shortlog

git shortlog résume les contributions par auteur :

git shortlog -sn --no-merges

   142  Alice
    87  Bob
    45  Carol

Options utiles :

Option	Effet
-s	Nombre de commits uniquement (pas de titres)
-n	Tri par nombre de commits décroissant
--no-merges	Exclut les commits de merge
--since="2026-01-01"	Depuis une date

Glissez pour voir

Pour analyser un répertoire :

git shortlog -sn -- src/utils/

Dépannage : problèmes courants

Symptôme	Cause probable	Solution
bisect propose des commits qui ne compilent pas	Certains commits intermédiaires cassent le build	git bisect skip ou code retour 125 dans le script
blame montre un commit de formatage pour toutes les lignes	Reformatage massif du code	Créer .git-blame-ignore-revs et configurer blame.ignoreRevsFile
log -S ne trouve rien	Le mot-clé n'a jamais été dans le diff	Essayez -G avec une regex, ou git grep "mot" pour chercher dans le contenu actuel
log -L :func:file ne reconnaît pas la fonction	Langage non détecté par les patterns Git	Ajoutez un pattern personnalisé dans .gitattributes
bisect run marque tout comme « bad »	Le script retourne toujours un code non-zéro	Testez le script manuellement sur un commit connu comme bon

Glissez pour voir

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

À retenir

• git bisect est l'outil le plus efficace pour trouver un commit coupable, il divise l'intervalle par 2 à chaque étape
• bisect run automatise la recherche avec un script qui retourne 0 (bon) ou 1 (mauvais)
• git blame révèle qui a modifié chaque ligne, utilisez .git-blame-ignore-revs pour exclure les commits de formatage
• git log -S (pickaxe) retrouve le commit qui a ajouté ou supprimé un mot-clé
• git log -L suit l'évolution d'une fonction ou d'un intervalle de lignes dans le temps
• git shortlog -sn donne une vue statistique des contributions

Pour aller plus loin

• Sélection de révisions : La façon de désigner sans ambiguïté le commit que l'enquête a identifié.
• Rechercher dans Git : git log -S et git grep, pour retrouver quand une ligne est apparue ou a disparu.
• Debug : bisect et blame : La recherche dichotomique du commit fautif, et l'attribution ligne par ligne.

×

📖 Voir la documentation →