7.1 Git-verktyg - Revisionsurval

Du kan naturligtvis referera till en enskild incheckning med dess fullständiga SHA‑1-hash på 40 tecken, men det finns också mer människovänliga sätt att referera till incheckningar. Detta avsnitt beskriver de olika sätt du kan referera till en incheckning.

Git är tillräckligt smart för att förstå vilken incheckning du menar om du anger de första tecknen i SHA‑1-hashen, så länge den delvisa hashens längd är minst fyra tecken och entydig; det vill säga, inget annat objekt i objektdatabasen kan ha en hash som börjar med samma prefix.

Till exempel, om du vill undersöka en specifik incheckning där du vet att du lade till viss funktionalitet, kan du först köra kommandot git log för att hitta incheckningen:

I det här fallet, säg att du är intresserad av incheckningen vars hash börjar med 1c002dd…​. Du kan inspektera den incheckningen med någon av följande varianter av git show (förutsatt att de kortare varianterna är entydiga):

Git kan räkna ut en kort, unik förkortning för dina SHA‑1-värden. Om du skickar --abbrev-commit till kommandot git log använder utdata kortare värden men håller dem unika; standard är sju tecken men de blir längre om det behövs för att hålla SHA‑1 entydig:

I allmänhet räcker åtta till tio tecken mer än väl för att vara unika inom ett projekt. Till exempel hade Linuxkärnan (som är ett ganska stort projekt) i februari 2019 över 875 000 incheckningar och nästan sju miljoner objekt i objektdatabasen, utan att två objekt hade identiska SHA‑1 i de första 12 tecknen.

Ett enkelt sätt att referera till en viss incheckning är om det är incheckningen längst ut på en gren; i så fall kan du helt enkelt använda grennamnet i vilket Git-kommando som helst som förväntar sig en referens till en incheckning. Om du till exempel vill titta på den senaste incheckningen på en gren är följande kommandon likvärdiga, förutsatt att grenen topic1 pekar på incheckningen ca82a6d…​:

Om du vill se vilken specifik SHA‑1 en gren pekar på, eller om du vill se vad något av exemplen i praktiken leder till i termer av SHA‑1, kan du använda ett Git-rörverktyg som heter rev-parse. Du kan läsa mer om rörverktyg i Git bakom kulisserna; kort sagt finns rev-parse för lågnivåoperationer och är inte tänkt för dagligt bruk. Det kan ändå vara hjälpsamt när du behöver se vad som faktiskt händer. Här kan du köra rev-parse på din gren.

En sak Git gör i bakgrunden medan du arbetar är att hålla en "referenslogg" – en logg över var dina HEAD- och grenreferenser har befunnit sig de senaste månaderna.

Du kan se din referenslogg med git reflog:

Varje gång spetsen på din gren uppdateras av någon anledning sparar Git den informationen åt dig i den här tillfälliga historiken. Du kan använda referenslogg-datan för att referera till äldre incheckningar också. Om du till exempel vill se det femte tidigare värdet av HEAD i ditt kodförråd kan du använda referensen @{5} som du ser i referenslogg-utdata:

Du kan också använda den här syntaxen för att se var en gren befann sig för en viss tid sedan. Till exempel, för att se var din master-gren var igår kan du skriva:

Detta visar var spetsen av din master-gren var igår. Tekniken fungerar bara för data som fortfarande finns i refloggen, så du kan inte använda den för att titta på incheckningar som är äldre än några månader.

För att se referenslogg-information formaterad som git log-utdata kan du köra git log -g:

Det är viktigt att notera att referenslogg-information är strikt lokal – det är en logg enbart över det du har gjort i ditt kodförråd. Referenserna kommer inte att vara desamma i någon annans kopia av kodförrådet; dessutom har du en tom referenslogg direkt efter att du klonat ett kodförråd, eftersom ingen aktivitet ännu skett i ditt kodförråd. Om du kör git show HEAD@{2.months.ago} kommer du bara se den matchande incheckningen om du klonade projektet för minst två månader sedan – klonade du det nyligen ser du bara din första lokala incheckning.

Det andra huvudsättet att ange en incheckning är via dess anfäder. Om du sätter ^ (cirkumflex) i slutet av en referens tolkar Git det som föräldern till den incheckningen. Anta att du tittar på historiken i ditt projekt:

Då kan du se föregående incheckning genom att ange HEAD^, vilket betyder "föräldern till HEAD":

Du kan också ange en siffra efter ^ för att identifiera vilken förälder du vill ha; till exempel betyder d921970^2 "den andra föräldern till d921970". Den här syntaxen är bara användbar för sammanslagningsincheckningar som har mer än en förälder – den första föräldern för en sammanslagningsincheckning kommer från grenen du var på när du sammanfogade (ofta master), medan den andra föräldern kommer från grenen som sammanfogades (till exempel topic):

Det andra huvudsättet att ange anfäder är ~ (tilde-tecknet). Det refererar också till den första föräldern, så HEAD~ och HEAD^ är likvärdiga. Skillnaden blir tydlig när du anger en siffra. HEAD~2 betyder "den första föräldern till den första föräldern", eller "farföräldern" – den går uppåt bland första föräldrar det antal gånger du anger. Till exempel, i historiken ovan skulle HEAD~3 bli:

Det kan också skrivas som HEAD~~~, vilket återigen är den första föräldern till den första föräldern till den första föräldern:

Du kan också kombinera dessa syntaxer – du kan få den andra föräldern till den föregående referensen (förutsatt att det var en sammanslagningsincheckning) genom att använda HEAD~3^2, och så vidare.

Nu när du kan ange enskilda incheckningar, låt oss se hur du anger intervall av incheckningar. Det är särskilt användbart när du hanterar grenar – om du har många grenar kan du använda intervallspecifikationer för att besvara frågor som "Vilket arbete finns i den här grenen som jag ännu inte har sammanfogat in i min huvudgren?".