Feilsøking med Git Bisect

Se for Dem at det oppstår en feil i prosjektet, men at De ikke vet hvilken nylig endring som forårsaket den. Det kan være svært tidkrevende å kontrollere hver commit manuelt!

git bisect er en kraftig Git-kommando som bruker en binærsøkealgoritme til raskt å finne den nøyaktige commiten som introduserte en feil.

Hvordan kan git bisect arbeide så raskt? Det fungerer omtrent som en «varmt eller kaldt»-lek med commit-historikken.

• De forteller Git hvilken commit De vet er dårlig (den inneholder feilen).
• De forteller Git hvilken commit De vet er god (fra før feilen eksisterte).
• Git velger en commit omtrent midt i intervallet og ber Dem teste den.
• Basert på tilbakemeldingen Deres halverer Git søkeområdet og gjentar prosessen til den skyldige commiten er funnet.

Først må De fortelle Git at De starter en bisect-økt. Deretter markerer De den kjente «dårlige» commiten (med feilen) og en kjent «god» commit (som fungerer).

De kan bruke commit-hasher, grennavn eller tagger.

Etter at De har angitt de gode og dårlige commitene, sjekker Git automatisk ut en commit midt i dette intervallet. Deres oppgave er å teste koden i denne commiten.

• Hvis feilen finnes, markerer De den som dårlig.
• Hvis feilen ikke finnes, markerer De den som god.

Git går deretter videre til neste commit og halverer det gjenværende søkeområdet.

Når De har testet den utsjekkede commiten, bruker De disse kommandoene til å fortelle Git om den er god eller dårlig:

• Markere den gjeldende commiten som dårlig: git bisect bad
• Markere den gjeldende commiten som god: git bisect good

Git sjekker deretter automatisk ut neste commit som skal testes.

De gjentar prosessen med å «teste og markere». For hvert trinn kommer git bisect nærmere den ene commiten som introduserte feilen. Det er mye raskere enn å kontrollere commitene én etter én!

For et område på 100 commits kreves det maksimalt 7 tester (log₂(100) ≈ 6,64).

Til slutt avgrenser git bisect området til én enkelt commit. Deretter rapporterer Git den første «dårlige» commiten som ble funnet – commiten som introduserte feilen!

Når feilen er funnet, er det viktig å avslutte bisect-økten for å føre arkivet tilbake til den opprinnelige tilstanden (vanligvis grenen De var på da De startet).

Noen ganger kan git bisect ende på en commit som ikke kan testes (for eksempel fordi den ikke kompilerer, eller fordi avhengigheter er ødelagt). I slike tilfeller kan De be Git hoppe over den:

git bisect skip

Git velger da en annen commit å teste og sørger for at den som ble hoppet over, ikke tas med i det mulige feilintervallet.

For enda raskere feilsøking kan De automatisere testprosessen ved hjelp av git bisect run. Denne kommandoen tar imot et skript som utfører testen og avsluttes med bestemte koder:

• 0: Commiten er god.
• 1-127 (unntatt 125): Commiten er dårlig.
• 125: Commiten skal hoppes over (for eksempel fordi den ikke kan bygges).

Git kjører deretter skriptet automatisk for hver commit til feilen er funnet.

De har mestret git bisect! Dette kraftige verktøyet gjør feilsøking fra en kjedelig oppgave til en effektiv og systematisk prosess ved hjelp av binærsøk.

• Start med git bisect start, og definer gode og dårlige commits.
• Test og marker commits som good eller bad.
• Bruk git bisect skip for commits som ikke kan testes.
• Automatiser med git bisect run for rask, automatisert feilsøking.
• Avslutt alltid med git bisect reset.

Lykke til med feilsøkingen!