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

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

Lancez la session bisect
Fenêtre de terminal
```
git bisect start
```
Indiquez le commit actuel comme mauvais
Fenêtre de terminal
```
git bisect bad
```
Git utilise HEAD par défaut. Vous pouvez spécifier un SHA : git bisect bad a1b2c3d.
Indiquez un commit où tout fonctionnait
Fenêtre de terminal
```
git bisect good v1.2.0
```
Utilisez un tag, un SHA, ou tout identifiant de commit.
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 :
Fenêtre de terminal
```
# Si le bug est présent :
git bisect bad

# Si le bug est absent :
git bisect good
```

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

Terminez la session bisect
Fenêtre de terminal
```
git bisect reset
```
Cela restaure HEAD à la position d’avant le bisect.

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)

#!/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.

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

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

À 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

Prochaines étapes

Récupérer des données perdues Reflog, fsck, ORIG_HEAD : retrouvez vos commits perdus.

Annuler et corriger des commits Amend, revert, reset : toutes les techniques d'annulation.

Chercher dans l'historique Git grep, log --all, log -S et autres techniques de recherche.