1.3 Kom igång - Vad är Git?

Den stora skillnaden mellan Git och alla andra VCS:er (Subversion med flera) är hur Git ser på sina data. Konceptuellt lagrar de flesta andra system information som en lista med filändringar. De systemen (CVS, Subversion, Perforce och så vidare) ser informationen de lagrar som en uppsättning filer och ändringarna som gjorts i varje fil över tid (detta brukar kallas deltabaserad versionshantering).

Git lagrar inte sina data på det sättet. I stället ser Git sina data som en serie ögonblicksbilder av ett litet filsystem. Varje gång du gör en incheckning eller sparar läget för projektet tar Git i praktiken en bild av hur alla filer ser ut just då och sparar en referens till den ögonblicksbilden. För att vara effektiv sparar Git inte en fil igen om den inte ändrats, utan bara en länk till den tidigare identiska filen som redan finns. Git tänker alltså på sina data som ett flöde av ögonblicksbilder.

Det här är en viktig skillnad mellan Git och nästan alla andra VCS:er. Den gör att Git ändrar nästan varje del av versionshanteringen som de flesta andra system bara kopierade från föregående generation. Det gör Git mer likt ett litet filsystem med några otroligt kraftfulla verktyg ovanpå, snarare än ett VCS. Vi utforskar några av fördelarna med att tänka på data på detta sätt när vi går igenom grenar i Git-grenar.

De flesta åtgärder i Git behöver bara lokala filer och resurser – i regel krävs ingen information från en annan dator i nätverket. Om du är van vid ett centraliserat VCS där de flesta åtgärder har nätverksfördröjning kommer denna funktion i Git få dig att tro att hastighetsgudarna har välsignat Git med övernaturliga krafter. Eftersom du har hela projektets historik på den lokala disken verkar de flesta åtgärder nästan omedelbara.

Till exempel behöver Git inte kontakta en server för att bläddra i historiken – den läser den direkt från din lokala databas. Det betyder att du ser projektets historik nästan omedelbart. Om du vill se ändringarna mellan den nuvarande versionen av en fil och den som fanns för en månad sedan kan Git ta fram filen från förra månaden och göra en lokal jämförelse, i stället för att be en fjärrserver göra det eller hämta en äldre version och göra jämförelsen lokalt.

Det innebär också att du kan göra nästan allt även utan uppkoppling eller VPN. Om du sitter på ett flygplan eller tåg och vill göra lite arbete kan du göra incheckningar glatt (till din lokala kopia, kom ihåg) tills du får en nätverksanslutning för att skicka dina ändringar. Om du kommer hem och inte får igång VPN-klienten kan du ändå arbeta. I många andra system är det antingen omöjligt eller väldigt krångligt. I Perforce kan du till exempel inte göra mycket om du inte är ansluten till servern; i Subversion och CVS kan du redigera filer men du kan inte göra en incheckning av ändringarna i din databas (eftersom du saknar uppkoppling). Det kanske inte låter så viktigt, men du kommer att märka stor skillnad i praktiken.

Allt i Git får en kontrollsumma innan det lagras och refereras sedan via den kontrollsumman. Det betyder att det är omöjligt att ändra innehållet i någon fil eller katalog utan att Git märker det. Funktionen är inbyggd i Git på de lägsta nivåerna och är en grundpelare i dess filosofi. Du kan inte tappa information på vägen eller få en korrupt fil utan att upptäcka det.

Mekanismen som Git använder kallas en SHA‑1‑summa. Det är en sträng på 40 tecken som består av hexadecimala tecken (0–9 och a–f) och beräknas från innehållet i en fil eller katalogstruktur i Git. En SHA‑1‑summa ser ut ungefär så här:

Du kommer att se dessa kontrollsummor överallt i Git eftersom Git använder dem så mycket. Faktum är att Git lagrar allt i sin databas utifrån innehållets kontrollsumma, inte filnamnet.

När du gör saker i Git leder nästan allt till att data läggs till i Git‑databasen. Det är svårt att få systemet att göra något som inte går att ångra eller att radera data på något sätt. Som med alla VCS:er kan du förlora eller ställa till ändringar som du inte har gjort en incheckning av ännu, men när du väl har gjort en incheckning av en ögonblicksbild är den svår att bli av med, särskilt om du regelbundet skickar dina ändringar vidare till ett annat kodförråd.

Det gör Git till ett nöje att använda, eftersom vi vet att vi kan experimentera utan att riskera att ställa till det ordentligt. För en mer ingående beskrivning av hur Git lagrar sina data och hur du kan återställa sådant som verkar förlorat, se Ångra saker.

Var uppmärksam nu – det här är det viktigaste du behöver komma ihåg om Git för att resten av inlärningen ska gå smidigt. Git har tre huvudtillstånd som dina filer kan befinna sig i: ändrad, köad och incheckad:

Det leder oss till de tre huvuddelarna i ett Git‑projekt: arbetskatalogen, köytan och Git‑katalogen.

Arbetskatalogen är en enskild arbetskopia av en version av projektet. Filerna plockas ut ur den komprimerade databasen i Git‑katalogen på disken så att du kan använda eller ändra dem.

Köytan är en fil, vanligtvis inuti Git‑katalogen, som lagrar information om vad som ska ingå i nästa incheckning. Dess tekniska namn i Git är “index”, men “köytan” fungerar lika bra.

Git‑katalogen är där Git lagrar metadata och objektdatabasen för ditt projekt. Det är den viktigaste delen av Git och det är den som kopieras när du klonar ett kodförråd från en annan dator.

Det grundläggande arbetsflödet i Git ser ungefär ut så här:

Om en viss version av en fil finns i Git‑katalogen räknas den som incheckad. Om den har ändrats och lagts till i köytan är den köad. Och om den har ändrats efter att den togs ut men inte köades är den ändrad. I Grunderna i Git får du lära dig mer om dessa tillstånd och hur du antingen kan dra nytta av dem eller hoppa över köytan helt.