7.10 Git-verktyg - Felsöka med Git

Om du spårar ett programfel i din kod och vill veta när det introducerades och varför, är filannotering ofta ditt bästa verktyg. Det visar vilken incheckning som senast ändrade varje rad i en fil. Så om du ser att en metod i din kod är felaktig kan du annotera filen med git blame för att avgöra vilken incheckning som var ansvarig för att den raden introducerades.

Följande exempel använder git blame för att avgöra vilken incheckning och incheckare som var ansvarig för rader i Linuxkärnans Makefile på toppnivå och använder dessutom flaggan -L för att begränsa utdata till raderna 69–82 i filen:

Observera att det första fältet är den förkortade SHA‑1:an för incheckningen som senast ändrade raden. De två nästa fälten är värden som hämtats från den incheckningen — författarnamn och författardatum — så att du lätt kan se vem som ändrade raden och när. Efter det kommer radnumret och filens innehåll. Notera också ^1da177e4c3f4‑raderna, där ^‑prefixet markerar rader som infördes i kodförrådets första incheckning och har varit oförändrade sedan dess. Det kan vara förvirrande, eftersom du nu har sett minst tre sätt som Git använder ^ för att modifiera en SHA-1-referens, men här är det just den betydelsen som gäller.

En annan cool sak med Git är att den inte spårar filnamnsbyten explicit. Den registrerar ögonblicksbilder och försöker sedan lista ut vad som byttes namn implicit i efterhand. En intressant följd av detta är att du kan be den räkna ut alla möjliga kodförflyttningar också. Om du skickar flaggan -C till git blame analyserar Git filen du annoterar och försöker räkna ut var kodsnuttar i den ursprungligen kom ifrån om de kopierades från någon annanstans. Till exempel, säg att du refaktorerar en fil med namnet GITServerHandler.m till flera filer, där en av dem är GITPackUpload.m. Genom att köra git blame på GITPackUpload.m med flaggan -C kan du se var kodavsnitt ursprungligen kom ifrån:

Det är verkligen användbart. Normalt får du som ursprunglig incheckning den incheckning där du kopierade koden, eftersom det är första gången du rörde de raderna i filen. Git talar om vilken incheckning du skrev de raderna i från början, även om det var i en annan fil.

Att annotera en fil hjälper om du redan vet var problemet finns. Om du inte vet vad som går sönder och det har gått dussintals eller hundratals incheckningar sedan den senaste versionen där du vet att koden fungerade, kommer du sannolikt att använda git bisect för hjälp. Kommandot bisect gör en bisektering i din incheckningshistorik för att hjälpa dig identifiera så snabbt som möjligt vilken incheckning som introducerade problemet.

Säg att du just har publicerat en utgåva av din kod till en produktionsmiljö, du får felrapporter om något som inte hände i din utvecklingsmiljö, och du kan inte förstå varför koden beter sig så. Du går tillbaka till koden och upptäcker att du kan återskapa problemet, men du kan inte lista ut vad som går fel. Du kan bisektera koden för att ta reda på det. Först kör du git bisect start för att komma igång, och sedan använder du git bisect bad för att tala om för systemet att den incheckning du står på är trasig. Sedan måste du tala om för bisekteringen när det senaste kända bra läget var, med git bisect good <bra_incheckning>:

Git räknade ut att ungefär 12 incheckningar låg mellan incheckningen du markerade som senaste bra (v1.0) och den nuvarande trasiga versionen, och växlade till den mittersta åt dig. Vid det här laget kan du köra ditt test för att se om problemet finns i den här incheckningen. Om det gör det introducerades det någon gång före den här mittersta incheckningen; om det inte gör det introducerades problemet någon gång efter den mittersta incheckningen. Det visar sig att det inte finns något problem här, och du talar om för Git genom att skriva git bisect good och fortsätter din resa:

Nu är du på en annan incheckning, halvvägs mellan den du just testade och din trasiga incheckning. Du kör ditt test igen och upptäcker att den här incheckningen är trasig, så du talar om det för Git med git bisect bad:

Den här incheckningen är bra, och nu har Git all information den behöver för att avgöra var problemet introducerades. Den talar om SHA‑1:an för den första trasiga incheckningen och visar en del av incheckningsinformationen och vilka filer som ändrades i den incheckningen så att du kan lista ut vad som hände som kan ha introducerat programfelet:

När du är klar bör du köra git bisect reset för att återställa din HEAD till där du var innan du började, annars hamnar du i ett märkligt läge:

Det är ett kraftfullt verktyg som kan hjälpa dig att kontrollera hundratals incheckningar efter ett introducerat programfel på några minuter. Faktum är att om du har ett skript som returnerar 0 om projektet är bra eller något annat än 0 om projektet är dåligt kan du helt automatisera git bisect. Först anger du återigen intervallet för bisekteringen genom att ange den kända dåliga och den kända bra incheckningen. Du kan göra detta genom att lista dem med kommandot bisect start om du vill, och lista den kända dåliga incheckningen först och den kända bra incheckningen som tvåa:

När du gör det körs test-error.sh automatiskt på varje utlagd incheckning tills Git hittar den första trasiga incheckningen. Du kan också köra något som make eller make tests eller vad du nu har som kör automatiserade tester åt dig.