Synopsis
git bisect start
git bisect good <commit>
git bisect bad <commit>
git bisect run <script>
git bisect reset
Description
The git bisect command performs a binary search through commit history to identify exactly which commit introduced a bug. You start by marking a known-bad commit (often HEAD) and a known-good commit (perhaps a release tag), then Git checks out a midpoint and asks you to test. You answer "good" or "bad," Git narrows the range, and you repeat until the offending commit is found.
If you have an automated test or reproducer, git bisect run automates the entire process — Git invokes your script at each step. Bisecting through a thousand commits typically takes about ten iterations.
Dans l'usage quotidien, git bisect s'intègre étroitement avec les alias de shell, les plugins d'éditeur et l'intégration continue. Les utilisateurs avancés ajoutent souvent des alias combinant les flags qu'ils passent toujours, ou enveloppent la commande dans des scripts qui appliquent les conventions d'équipe. Le formatage de la sortie peut être personnalisé via la configuration Git — pretty formats, schémas de couleurs et comportement du pager sont tous ajustables. Quand quelque chose tourne mal, la première étape de diagnostic est généralement de relancer la commande avec GIT_TRACE=1 dans l'environnement, ce qui révèle les appels de plomberie sous-jacents. Pour les situations inhabituelles, la sortie --help (git bisect --help) ouvre la page de manuel complète avec les détails de chaque option, y compris celles rarement utilisées dans les workflows ordinaires mais essentielles pour le débogage ou le scripting à grande échelle.
Comprendre comment git bisect interagit avec le reste du modèle de données de Git — la base d'objets, l'index, les refs et l'arborescence de travail — est rentable. Chaque commande opère sur un sous-ensemble de ces pièces, et savoir laquelle elle touche aide à prédire les résultats et récupérer après les erreurs. Lire la documentation officielle de Git en parallèle de la pratique sur un dépôt jetable est la façon la plus rapide d'intérioriser les subtilités. La plupart des problèmes de production avec Git proviennent de l'une de trois causes : comportement par défaut surprenant, opérations réseau partielles, ou réécriture d'historique déjà partagé. Un modèle mental fonctionnel des effets de bord de git bisect aide à éviter les trois.
Options courantes
| Sous-commande | Description |
|---|---|
start | Commencer une session de bisect. |
good / bad | Marquer le commit courant (ou spécifié). |
skip | Marquer un commit comme non testable. |
run <cmd> | Automatiser en exécutant une commande (sortie 0 = good, non nulle = bad). |
reset | Terminer la session et retourner sur la branche d'origine. |
log | Afficher le log de bisect. |
visualize | Afficher les commits suspects restants. |
Exemples
git bisect start
git bisect bad HEAD
git bisect good v1.5.0
# Git fait un checkout d'un point milieu ; testez-le puis :
git bisect good # ou : git bisect bad
git bisect run npm test
# Entièrement automatisé : les codes de sortie de npm test pilotent la recherche
git bisect reset
# Retourner sur votre branche d'origine
Erreurs fréquentes
Forgetting to git bisect reset leaves you in a detached HEAD state. Marking a commit "good" when the bug is intermittent leads bisect astray — use skip instead. Make sure your test script returns exit code 125 to signal "skip" if the build itself is broken at that commit.
Commandes liées
git log, git blame, git show, git checkout