Lancer une recherche binaire avec git bisect

Quand un défaut apparaît sur le site, examiner les commits un par un peut prendre beaucoup de temps. git bisect vous fait tester des révisions choisies pour réduire rapidement la période où la régression a été introduite. Vous fournissez les verdicts ; Git organise la recherche.

Préparer les deux bornes de recherche

Vous avez déjà défini un contrôle reproductible pour distinguer un état sain d’un état défectueux. Réutilisez ce même contrôle à chaque étape : changer de critère pendant la recherche rendrait les verdicts incohérents. Avant de commencer, repérez une révision où le défaut est présent et une révision antérieure où il est absent.

Dans l’exemple, la branche de travail courante contient le défaut et `main~20` désigne un ancêtre suffisamment ancien pour être sain. Cette référence suppose que l’historique comporte au moins vingt premiers parents et que le défaut se situe dans cet intervalle ; adaptez-la à votre dépôt. Un point de départ trop récent, ou déjà défectueux, ne permet pas de trouver le bon commit fautif.

Démarrer la recherche

La commande de démarrage active bisect et marque les deux bornes en une seule fois. La révision courante, ici `HEAD`, est déclarée mauvaise ; `main~20` est déclarée bonne. Git choisit alors une révision intermédiaire et place votre copie de travail sur celle-ci pour que vous appliquiez le contrôle.

git bisect start HEAD main~20

Bisecting: 9 revisions left to test after this (roughly 3 steps)
[abc1234] Mise à jour de la navigation

Le hash et le nombre de révisions affichés sont propres à chaque dépôt ; ils ne sont qu’un exemple. Sur la révision sélectionnée, exécutez votre contrôle du défaut. Si la page est saine, indiquez-le avec `git bisect good` ; si le défaut est présent, utilisez `git bisect bad`. Git conserve ce verdict et sélectionne une autre révision située dans l’intervalle restant.

Répéter les verdicts jusqu’au commit fautif

Répétez le cycle sans modifier le critère : tester la page sur la révision courante, puis la marquer bonne ou mauvaise. Une fois le verdict enregistré, attendez que Git affiche la révision suivante avant de relancer le contrôle. Ne tirez pas de conclusion à partir d’un seul changement apparent : la recherche continue jusqu’à ce que Git puisse désigner la première révision qui introduit le défaut.

# À chaque révision proposée, après avoir exécuté le contrôle :
git bisect good
# ou, si le défaut est présent :
git bisect bad

Bisecting: 4 revisions left to test after this (roughly 2 steps)
[def5678] Ajustement de la page d’accueil

Quand l’intervalle est réduit à un seul changement pertinent, Git annonce le commit qui a fait passer l’état de bon à mauvais. Le résultat identifie une révision à examiner ; il ne constitue pas encore une explication de la cause. L’inspection du changement et sa confirmation feront l’objet d’une leçon ultérieure.

Terminer la session

Une recherche terminée laisse normalement votre copie de travail sur la révision fautive. Exécutez `git bisect reset` pour mettre fin à la session et revenir à la branche ou à la révision qui était active avant le démarrage. Faites-le également si vous interrompez la recherche ; vous éviterez de poursuivre le travail par erreur dans un état intermédiaire.

git bisect reset

Previous HEAD position was def5678 Ajustement de la page d’accueil
Switched to branch 'feature/correction-navigation'

À retenir

• Marquez une révision défectueuse et une révision saine pour encadrer la recherche.
• Appliquez exactement le même contrôle reproductible à chaque révision proposée.
• Enregistrez chaque verdict avec `git bisect good` ou `git bisect bad`.
• Terminez la session avec `git bisect reset` pour retrouver votre branche de travail.
• Le commit identifié est un point de départ pour l’analyse ; il reste à confirmer et à expliquer.