Calculateur d'Étapes Git Bisect | Estimez les tours et le temps pour trouver une régression

Avant de lancer une session git bisect, il est utile de savoir combien de réponses sain/défectueux vous devrez fournir. Saisissez le nombre de commits et cet outil renvoie le nombre d'étapes nécessaires sous la forme ceil(log2(N)), un temps total estimé d'après votre durée de compilation par étape et une vue de la plage que la recherche binaire divise par deux à chaque tour.

💡 À propos de cet outil

git bisect effectue une recherche binaire entre un commit dont vous savez qu'il fonctionnait et un autre dont vous savez qu'il échoue, isolant le commit fautif en temps O(log N). Sur 1000 commits, les examiner un par un pourrait demander jusqu'à 1000 compilations ; la recherche binaire n'en réclame qu'une dizaine.

La friction se situe surtout au démarrage : quand l'intégration continue prend plusieurs minutes par exécution, vous voulez savoir si vous vous engagez pour 7 tours ou pour 20 avant de lancer la session. Ce calculateur déduit le nombre d'étapes de la plage de commits avec ceil(log2(N)) et le multiplie par votre temps de compilation par étape pour estimer le total. Si vous savez déjà à peu près où se trouvent le dernier commit sain et le premier commit défectueux, renseignez ces positions et la plage de recherche se réduit, abaissant à la fois les étapes et le temps. C'est un moyen rapide de voir à quel point restreindre la plage est rentable.

🧐 Questions fréquentes

Comment le nombre d'étapes est-il calculé ? Il prend le nombre de commits de la plage comme N et renvoie ceil(log2(N)). Chaque étape de bisect divise par deux la plage restante : c'est donc le nombre de divisions nécessaires pour ramener N à un seul commit. Lorsque N vaut 1, le résultat est 0 étape car il n'y a plus rien à diviser.

Dois-je obligatoirement indiquer les positions sain et défectueux ? Non. Laissez-les vides et l'outil considère le commit sain comme le début de l'historique (0) et le commit défectueux comme le plus récent (HEAD), en utilisant le total des commits comme plage. Les renseigner limite la recherche à cet intervalle, ce qui réduit les étapes et le temps estimé.

Quelle est la précision du temps estimé ? C'est une simple multiplication du nombre d'étapes par votre temps par étape. Indiquez la durée moyenne de votre compilation ou de votre test manuel et vous obtenez un ordre de grandeur ; il ne tient pas compte des attentes en file de l'intégration continue ni des pauses et reprises du bisect. Utilisez-le comme une idée d'échelle avant de commencer.

git bisect run change-t-il le nombre de tours ? Non. git bisect run <script> automatise seulement le verdict sain/défectueux de chaque étape ; la recherche binaire effectue toujours le même nombre de divisions. Que vous répondiez à la main ou qu'un script réponde, l'estimation des étapes reste valable.

📚 Pourquoi la recherche binaire reste rapide

Le mot « bisect » signifie couper en deux. Diviser la plage par deux à chaque tour réduit de moitié les candidats à chaque fois ; atteindre un seul commit à partir de N ne coûte donc que « combien de fois peut-on diviser N par 2 avant d'atteindre 1 » — c'est log2(N). Doubler le nombre de commits n'ajoute qu'une seule étape : environ 10 tours pour 1000 commits, et près de 20 même pour un million. Cette croissance quasi plate est précisément ce qui rend bisect praticable sur d'énormes dépôts. Une nuance : les commits qui ne compilent pas peuvent être mis de côté avec git bisect skip, mais à mesure que les skip s'accumulent, il reste moins de divisions nettes, si bien que le nombre réel de tours peut dépasser légèrement la valeur théorique.