Debuggen met Git Bisect

Stel dat er een fout in je project verschijnt, maar je niet weet welke recente wijziging deze heeft veroorzaakt. Elke commit handmatig controleren kan enorm veel tijd kosten!

git bisect is een krachtige Git-opdracht die een binair zoekalgoritme gebruikt om snel de exacte commit te vinden die een fout heeft geïntroduceerd.

Hoe werkt git bisect zo snel? Het lijkt op een spelletje ‘warm of koud’ met je commitgeschiedenis.

• Je vertelt Git welke commit je zeker slecht vindt (de fout bevat).
• Je vertelt Git welke commit je zeker goed vindt (van vóór het bestaan van de fout).
• Git kiest ongeveer de middelste commit en vraagt je die te testen.
• Op basis van je feedback halveert Git het zoekgebied en herhaalt dit totdat de boosdoener is gevonden.

Om te beginnen vertel je Git eerst dat je een bisect-sessie start. Daarna markeer je de bekende ‘slechte’ commit (met de fout) en een bekende ‘goede’ commit (die werkt).

Je kunt commit-hashes, branchnamen of tags gebruiken.

Nadat je je goede en slechte commits hebt gedefinieerd, checkt Git automatisch een commit in het midden van dat bereik uit. Het is jouw taak om de code bij deze commit te testen.

• Als de fout aanwezig is, markeer je de commit als slecht.
• Als de fout NIET aanwezig is, markeer je de commit als goed.

Git gaat vervolgens naar de volgende commit en halveert het resterende zoekgebied.

Nadat je de momenteel uitgecheckte commit hebt getest, gebruik je deze opdrachten om Git te vertellen of de commit goed of slecht is:

• De huidige commit als slecht markeren: git bisect bad
• De huidige commit als goed markeren: git bisect good

Git checkt vervolgens automatisch de volgende commit uit om te testen.

Je herhaalt het proces van ‘testen en markeren’. Bij elke stap komt git bisect dichter bij de ene commit die de fout heeft geïntroduceerd. Dat is veel sneller dan commits één voor één controleren!

Voor een bereik van 100 commits zijn maximaal 7 tests nodig (log₂(100) ≈ 6,64).

Uiteindelijk verkleint git bisect het bereik tot één commit. Vervolgens rapporteert Git de eerst gevonden ‘slechte’ commit: de commit die de fout heeft geïntroduceerd!

Nadat je de fout hebt gevonden, is het belangrijk om de bisect-sessie te verlaten, zodat je opslagplaats terugkeert naar de oorspronkelijke staat (meestal de branch waarop je werkte toen je begon).

Soms komt git bisect terecht bij een commit die niet kan worden getest (de code kan bijvoorbeeld niet worden gecompileerd of afhankelijkheden zijn defect). In zulke gevallen kun je Git vertellen deze commit over te slaan:

git bisect skip

Git kiest dan een andere commit om te testen en sluit de overgeslagen commit uit van het mogelijke bereik waarin de fout is ontstaan.

Voor nog sneller fouten opsporen kun je het testproces automatiseren met git bisect run. Deze opdracht gebruikt een script dat de test uitvoert en wordt afgesloten met specifieke codes:

• 0: De commit is goed.
• 1-127 (behalve 125): De commit is slecht.
• 125: De commit moet worden overgeslagen (kan bijvoorbeeld niet worden gebouwd).

Git voert het script vervolgens automatisch uit voor elke commit totdat de fout is gevonden.

Je beheerst git bisect! Met dit krachtige hulpmiddel verandert het zoeken naar fouten van een vervelende klus in een efficiënt, systematisch proces met binair zoeken.

• Begin met git bisect start en definieer goede en slechte commits.
• Test commits en markeer ze als good of bad.
• Gebruik git bisect skip voor commits die niet kunnen worden getest.
• Automatiseer met git bisect run voor snel debuggen zonder handmatig werk.
• Sluit altijd af met git bisect reset.

Veel succes met het opsporen van fouten!