Le principe de la recherche binaire appliquée au code

git bisect est une commande Git qui utilise le principe de la recherche binaire pour identifier le commit ayant introduit un bug. Au lieu de vérifier manuellement chaque modification, l'outil divise l'intervalle de commits suspects en deux à chaque étape, réduisant considérablement le nombre de vérifications nécessaires. Par exemple, pour quarante commits, environ six vérifications suffisent ; pour huit cents commits, une dizaine de vérifications sont nécessaires.

L'utilisateur indique à Git un commit où le code fonctionnait encore (marqué "good") et un commit où le bug est présent (marqué "bad"). Git sélectionne ensuite automatiquement le commit au milieu de cet intervalle et le présente à l'utilisateur pour évaluation. En fonction du résultat — bon ou mauvais — l'intervalle est réduit de moitié, et le processus se répète jusqu'à l'identification précise du commit fautif.

Déroulement d'une session Git Bisect

Pour lancer une session, la commande git bisect start est utilisée. L'état courant (généralement HEAD) est marqué comme défectueux avec git bisect bad. Un commit connu comme fonctionnel est ensuite désigné via git bisect good suivi d'un identifiant (hash, tag, branche ou version). Git bascule alors sur un commit intermédiaire et affiche le nombre de révisions restant à tester.

L'utilisateur doit tester l'application à ce stade. Si le bug est absent, il tape git bisect good ; s'il est présent, git bisect bad. Git répète l'opération jusqu'à trouver le commit responsable. En fin de session, un message indique par exemple "a3f8c12 is the first bad commit". Une fois la recherche terminée, il est impératif de revenir à l'état initial avec git bisect reset, faute de quoi le dépôt reste sur un commit détaché.

Automatisation avec des scripts de test

L'un des atouts majeurs de git bisect est sa capacité à s'automatiser via la commande git bisect run. Si un script de test retourne 0 en cas de succès et une valeur non nulle en cas d'échec, Git peut exécuter automatiquement ce test sur chaque commit candidat. Par exemple :

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

Cette approche fonctionne avec n'importe quelle commande ou script personnalisé : tests unitaires, vérifications de build, linting, scripts de validation d'API, etc. L'outil devient ainsi particulièrement utile pour le débogage de régressions, les échecs d'intégration continue ou les bugs survenus dans de grandes équipes.

Cas d'usage privilégiés

git bisect est recommandé dans plusieurs situations :

  • Bugs de régression : une fonctionnalité qui fonctionnait auparavant cesse de fonctionner.
  • Équipes nombreuses : avec de nombreux commits et une responsabilité floue, l'outil réduit le bruit.
  • Codebases anciennes : lorsque le moment exact du changement est oublié, l'historique du dépôt permet de retrouver la modification.
  • Échecs CI : un build échoue depuis plusieurs jours sans que la cause soit identifiée.

Malgré son efficacité, git bisect est souvent sous-utilisé par les développeurs, qui préfèrent inspecter manuellement l'historique, deviner les modifications probables ou blâmer les dépendances, des approches souvent plus longues et moins systématiques.