Lundi, le formulaire de connexion acceptait un compte de test. Vendredi, le même essai échoue et des dizaines de modifications séparent les deux versions. Git bisect aide à chercher le premier commit où un comportement devient observable. La méthode devient rapide quand vous pouvez reconnaître ce comportement avec un test court et stable. Sans ce repère, le résultat dépend surtout de la qualité de vos observations.
Trouver deux versions dont vous connaissez le résultat
Commencez par reproduire le défaut dans le code actuel. Identifiez ensuite une ancienne version où le même scénario passe. Ce peut être un tag de livraison ou le commit utilisé lors d’un test précédent. Utilisez les mêmes données et, autant que possible, les mêmes réglages de test. Un service externe en panne ou une base dont les données ont changé peut faire échouer les deux versions pour une raison étrangère au code.
Le test de référence doit produire une réponse claire. Pour un formulaire, une requête qui renvoie le code attendu avec un compte de test peut suffire. Gardez le message d’erreur et les conditions nécessaires pour le reproduire. Si le comportement échoue une fois sur cinq, travaillez d’abord à le rendre stable. Une seule classification erronée peut orienter la recherche vers la mauvaise moitié de l’historique.
Laisser Git choisir les commits intermédiaires
Travaillez depuis un répertoire propre. Si vous avez déjà une fonctionnalité en cours, vous pouvez préparer un dossier associé avec la méthode expliquée dans notre guide sur Git worktree. Ce répertoire sert aux changements de version successifs et vous permet de garder votre autre chantier ouvert.
Lancez git bisect start, puis marquez le commit défaillant avec git bisect bad suivi de sa référence. Indiquez ensuite le commit qui fonctionne avec git bisect good suivi de sa référence. Git choisit une révision intermédiaire. Lancez le test, puis indiquez simplement git bisect good si le problème n’apparaît pas ou git bisect bad s’il apparaît. Continuez jusqu’au résultat annoncé par Git. La documentation de git bisect décrit ce parcours, ses variantes et les options de reprise.
Si une révision ne compile pas pour une raison indépendante, utilisez git bisect skip après l’avoir examinée. Forcer cette révision dans la catégorie des mauvaises versions confondrait deux défauts. Plusieurs révisions ignorées près de la transition peuvent laisser un ensemble de commits possibles. Dans ce cas, relisez les différences et cherchez un moyen de tester les versions voisines dans des conditions compatibles.
Automatiser seulement un test déjà éprouvé
Vous pouvez faire exécuter une commande répétitive avec git bisect run. Avant de lui confier la série, lancez votre script manuellement sur les deux extrêmes. Vérifiez qu’il classe correctement les deux résultats et qu’il ne garde ni cache ni fichier produit par la révision précédente. Un test qui dépend de l’heure locale, d’une API distante ou d’un service de test partagé peut varier au fil des essais.
Respectez aussi les codes de sortie prévus par Git. Une réussite marque normalement une révision comme bonne. La valeur 125 sert à ignorer une révision que votre script ne peut pas tester. Une commande mal installée ou une étape de préparation qui échoue peut produire un autre code. Faites en sorte que ces erreurs soient visibles dans le journal de l’essai, au lieu de les faire passer pour le bogue recherché.
Examiner le résultat et refaire le scénario
Une fois le commit identifié, lisez sa différence et reproduisez le problème sur ce commit et sur un parent pertinent. La modification peut avoir introduit le défaut, ou seulement rendu visible un comportement déjà fragile. Un changement de dépendance peut notamment déclencher un problème dans une partie du code que le commit ne modifie pas. Cherchez ensuite le plus petit test qui démontre l’écart.
Conservez les références et le scénario dans le ticket, puis lancez git bisect reset pour quitter la session. Comme pour le diagnostic d’un incident applicatif, les références exactes aident quelqu’un d’autre à refaire le parcours. Le travail aboutit à une paire de versions vérifiables et à une différence ciblée, un point de départ solide pour corriger la régression.
Lorsque la régression concerne plusieurs systèmes, consignez celui utilisé pendant la recherche. La transition trouvée sur un poste peut dépendre d’une version précise du navigateur, d’une variable ou d’un pilote. Cette précision aide à choisir le test qui devra rester dans le projet.
Je suis Romain, rédacteur passionné par tout ce qui touche au high-tech, à la crypto, et à l’innovation. Diplômé d’une école de marketing à Paris, je mets ma plume au service des dernières tendances et avancées technologiques.
