Fejlfinding med Git Bisect

Forestil dig, at der opstår en fejl i dit projekt, men at du ikke ved, hvilken nylig ændring der forårsagede den. Det kan tage meget lang tid manuelt at kontrollere hvert commit!

git bisect er en effektiv Git-kommando, der bruger en binærsøgningsalgoritme til hurtigt at finde det præcise commit, der introducerede en fejl.

Hvordan kan git bisect arbejde så hurtigt? Det minder om en omgang "varm eller kold" med din commit-historik.

• Du fortæller Git, hvilket commit du ved er dårligt (det indeholder fejlen).
• Du fortæller Git, hvilket commit du ved er godt (fra før fejlen eksisterede).
• Git vælger et commit omtrent midt imellem og beder dig teste det.
• Ud fra din tilbagemelding halverer Git søgeområdet og gentager processen, indtil synderen er fundet.

Først skal du fortælle Git, at du starter en bisect-session. Derefter markerer du det kendte "dårlige" (fejlbehæftede) commit og et kendt "godt" (fungerende) commit.

Du kan bruge commit-hashværdier, grennavne eller tags.

Når du har defineret dine gode og dårlige commits, checker Git automatisk et commit ud midt i dette interval. Din opgave er at teste koden i dette commit.

• Hvis fejlen er til stede, skal du markere det som dårligt.
• Hvis fejlen IKKE er til stede, skal du markere det som godt.

Git går derefter videre til det næste commit og halverer det resterende søgeområde.

Når du har testet det aktuelt udcheckede commit, skal du bruge disse kommandoer til at fortælle Git, om det er godt eller dårligt:

• Sådan markeres det aktuelle commit som dårligt: git bisect bad
• Sådan markeres det aktuelle commit som godt: git bisect good

Git checker derefter automatisk det næste commit ud, der skal testes.

Du gentager processen med at teste og markere. For hvert trin kommer git bisect tættere på det ene commit, der introducerede fejlen. Det er meget hurtigere end at kontrollere commits ét ad gangen!

For et interval på 100 commits kræver det højst 7 tests (log₂(100) ≈ 6,64).

Til sidst indsnævrer git bisect intervallet til ét enkelt commit. Derefter rapporterer det det første fundne "dårlige" commit, som er det commit, der introducerede fejlen!

Når du har fundet fejlen, er det vigtigt at afslutte bisect-sessionen, så dit arkiv vender tilbage til sin oprindelige tilstand (som regel den gren, du var på, da du startede).

Nogle gange lander git bisect på et commit, der ikke kan testes (f.eks. fordi det ikke kan kompileres, eller fordi afhængighederne er ødelagt). I sådanne tilfælde kan du fortælle Git, at det skal springes over:

git bisect skip

Git vælger derefter et andet commit, der skal testes, og udelukker det oversprungne commit fra det mulige fejlsøgningsinterval.

Hvis du vil foretage fejlsøgningen endnu hurtigere, kan du automatisere testprocessen med git bisect run. Denne kommando tager et script, der udfører testen og afslutter med bestemte koder:

• 0: Commit'et er godt.
• 1-127 (undtagen 125): Commit'et er dårligt.
• 125: Commit'et skal springes over (f.eks. fordi det ikke kan bygges).

Git kører derefter automatisk scriptet for hvert commit, indtil fejlen er fundet.

Du har lært git bisect! Dette effektive værktøj forvandler fejlsøgning fra en kedelig opgave til en effektiv, systematisk proces ved hjælp af binærsøgning.

• Start med git bisect start, og definér gode og dårlige commits.
• Test og markér commits som good eller bad.
• Brug git bisect skip til commits, der ikke kan testes.
• Automatisér med git bisect run for hurtig fejlsøgning uden manuel indgriben.
• Afslut altid med git bisect reset.

God fornøjelse med fejlsøgningen!