Recherche binaire dans l'histoire

git bisect effectue une recherche binaire à travers les commits pour trouver celui qui a introduit un bug. Étant donné un commit connu comme bon et un connu comme mauvais, Git extrait des commits au milieu et vous demande de tester. Chaque réponse divise l'espace de recherche par deux, donc 1024 commits se résolvent en environ 10 étapes.

Session manuelle de bisect

git bisect start
git bisect bad                    # le commit actuel est mauvais
git bisect good v2.4.0            # ce tag plus ancien était bon
# Git extrait le point médian
# Testez le build, puis :
git bisect bad                    # ou : git bisect good
# Continuez jusqu'à ce que Git nomme le premier mauvais commit
git bisect reset                  # revenir à la branche d'origine

Termes personnalisés

Parfois "good/bad" n'est pas le bon vocabulaire — par exemple, lors d'un bisect d'une régression de performance vous pourriez préférer "fast/slow" :

git bisect start --term-old fast --term-new slow
git bisect slow
git bisect fast v2.4.0

Sauter les commits non testables

Si le commit extrait ne peut pas être testé, utilisez git bisect skip. Git choisira un commit voisin et s'ajustera.

git bisect skip
git bisect skip <sha1> <sha2>

Visualiser

git bisect visualize
git bisect log > bisect.log
git bisect replay bisect.log

Restreindre la recherche

Si vous soupçonnez que la régression se trouve dans un sous-répertoire :

git bisect start -- src/parser/

Erreurs courantes

Oublier de marquer les points extrêmes initiaux — Git ne peut pas bisecter sans un bon et un mauvais. Marquer un commit incorrectement empoisonne la recherche.

Bisect par premier parent

Depuis Git 2.29, --first-parent indique de suivre uniquement le premier parent de chaque merge :

git bisect start --first-parent