Felsökning med Git Bisect

Föreställ er att en bugg dyker upp i projektet, men att ni inte vet vilken av de senaste ändringarna som orsakade den. Att manuellt kontrollera varje commit kan ta väldigt lång tid!

git bisect är ett kraftfullt Git-kommando som använder en binärsökningsalgoritm för att snabbt hitta exakt vilken commit som introducerade en bugg.

Hur kan git bisect arbeta så snabbt? Det liknar en lek med ”varmare eller kallare” genom er commit-historik.

• Ni anger en commit som ni vet är dålig (den innehåller buggen).
• Ni anger en commit som ni vet är bra (från innan buggen fanns).
• Git väljer en commit ungefär mitt i intervallet och ber er testa den.
• Utifrån ert svar halverar Git sökområdet och upprepar processen tills den skyldiga commit hittas.

Börja med att tala om för Git att ni startar en bisect-session. Markera sedan den kända ”dåliga” committen (med buggen) och en känd ”bra” commit (som fungerar).

Ni kan använda commit-hashar, grennamn eller taggar.

När ni har angett era bra och dåliga commits checkar Git automatiskt ut en commit mitt i intervallet. Er uppgift är att testa koden i denna commit.

• Om buggen finns, markerar ni den som dålig.
• Om buggen INTE finns, markerar ni den som bra.

Git går sedan vidare till nästa commit och halverar det återstående sökområdet.

När ni har testat den utcheckade committen använder ni följande kommandon för att tala om för Git om den är bra eller dålig:

• Markera den aktuella committen som dålig: git bisect bad
• Markera den aktuella committen som bra: git bisect good

Git checkar sedan automatiskt ut nästa commit som ska testas.

Ni upprepar processen ”testa och markera”. För varje steg kommer git bisect närmare den enda commit som introducerade buggen. Det går mycket snabbare än att kontrollera commits en i taget!

För ett intervall på 100 commits krävs högst 7 tester (log₂(100) ≈ 6,64).

Till slut avgränsar git bisect intervallet till en enda commit. Därefter rapporterar Git den första hittade ”dåliga” committen, alltså committen som introducerade buggen!

När buggen har hittats är det viktigt att avsluta bisect-sessionen, så att repositoriet återgår till sitt ursprungliga tillstånd (vanligtvis den gren ni befann er på när ni började).

Ibland kan git bisect hamna på en commit som inte går att testa (till exempel för att den inte kompilerar eller för att beroenden är trasiga). I sådana fall kan ni tala om för Git att hoppa över den:

git bisect skip

Git väljer då en annan commit att testa och ser till att den överhoppade committen inte ingår i det möjliga intervallet för buggen.

För ännu snabbare felsökning kan ni automatisera testprocessen med git bisect run. Kommandot tar ett skript som utför testet och avslutas med specifika koder:

• 0: Committen är bra.
• 1-127 (utom 125): Committen är dålig.
• 125: Committen ska hoppas över (till exempel om den inte kan byggas).

Git kör sedan skriptet automatiskt för varje commit tills buggen hittas.

Ni behärskar git bisect! Det här kraftfulla verktyget gör felsökning från ett tidskrävande arbete till en effektiv och systematisk process med binärsökning.

• Börja med git bisect start och ange bra och dåliga commits.
• Testa och markera commits som good eller bad.
• Använd git bisect skip för commits som inte kan testas.
• Automatisera med git bisect run för snabb felsökning utan manuellt arbete.
• Avsluta alltid med git bisect reset.

Lycka till med bugjakten!