Git
Chapters ▾ 2nd Edition

1.3 Kom igång - Vad är Git?

Vad är Git?

Vad är Git i ett nötskal? Detta är ett viktigt avsnitt att greppa, eftersom om du förstår vad Git är och det grunderna i hur det fungerar, så kommer det bli mycket enklare för dig att använda Git effekivt. När du nu lär dig Git, försök att rensa huvudet på sådant som har med andra versionshanteringssystem, som t.ex. CVS, Subversion eller Perforce — detta för att undvika att blanda ihop saker när du lär dig Git. Trots att Gits användargränssnitt är hyfsat likt andra versionshanterinssystem, så lagrar och tänker Git på information på ett annat sätt, och att förstå dessa skilnader kommer vara fördelaktigt för att undvika att blanda ihop det med andra verktyg.

Ögonblicksbilder (snapshots), inte skillnader

Den största skillnaden mellan Git och andra versionshanteringssystem (Subversion och liknande) är hur Git tänker på data. Konceptuellt så sparar de flesta andra system information som en lista av filändringar. De andra systemen (CVS, Subversion, Perforce, Bazaar, och så vidare) tänker på informationen de lagrar som en uppsättning filer och ändringarna som gjorts i varje fil över tid (detta kallas vanligen för deltabaserad versionshantering).

Lagrar data som ändringar till en basversion av varje fil.
Figure 4. Lagrar data som ändringar till en basversion av varje fil.

Git tänker inte på eller lagrar sin data på detta sättet. Istället ser Git sina data som en serie ögonblicksbilder av ett miniatyrfilsystem. Varje gång du gör förbinder eller sparar tillståndet i ditt projekt i Git, så tar egentligen Git en bild över hur alla dina filer ser ut för ögonblicket och sparar en referens till den ögonblicksbilden. För att vara effektiv, sparas inte en fil igen ifall den inte har ändrats, utan endast en länk till föregående identiska fil som redan lagrats. Git tänker på sina data som en ström av ögonblicksbilder

Lagrar data som ögonblicksbilder av projektet över tid.
Figure 5. Lagrar data som ögonblicksbilder av projektet över tid.

Detta är en viktig distinktion mellan Git och nästan alla andra versionshanteringsystem. Det gör att Git omprövar nästan varje aspekt av versionshantering som de flesta andra versionshanteringssystem kopierat från den föregående generationen. Detta gör Git mer likt ett minifilsystem med några extremt kraftfulla verktyg ovanpå det, snarare än endast ett versionshanteringssystem. Vi kommer att utforska några av fördelarna man får genom att tänka på data på detta sätt, när vi går igenom Git branching i Git Branching.

Nästan varje operation är lokal

De flesta operationer i Git behöver endast lokala filer och resurser för att fungera — generellt behövs ingen annan information från en annan dator på ditt nätverk. Om du är van vid ett centraliserat versionshanteringssystem där de flesta operationerna har viss nätverksfördröjning, kommer denna aspekt av Git få dig att tro att snabbhetsgudarna har välsignat Git med världsfrämmande krafter. Eftersom du har hela historiken av ditt projekt direkt på din lokala hårddisk, verkar alla operationer ske närmast ögonblickliga.

Till exempel, för att bläddra i projekthistoriken behöver inte Git kontakta en server för att hämta historiken — den bara läser direkt från din lokala databas. Detta betyder att du ser projekthistoriken närmast ögonblickligen. Om du vill se ändringar som introducerades mellan nuvarande version av filen och för en månad sedan, kan Git tar reda på hur filen såg ut förra månaden och göra en lokal jämförelse istället för att att be en server göra det eller hämta en äldre version från en server och göra det lokalt.

Sammantaget innebär detta att det finns väldigt lite du inte kan göra om du är offline eller inte har VPN. Om du är på ett flygplan eller ett tåg och vill göra lite jobb, kan du göra det och förbinda gladeligen (till din lokala kopia, eller hur?) tills du får tillgång till en nätverksanslutning för att skicka dina ändringar. Om du åker hem och inte kan få igång din VPN klient ordentligt, kan du fortfarande jobba. I många andra system är detta antingen omöjigt eller väldigt omständligt. Till exempel, i Perforce, kan du inte göra mycket ifall du inte är ansluten till en server; i Subversion och CVS kan du editera filer, men inte spara ändringarna till din databas (eftersom att den är offline). Detta kanske inte verkar vara en stor sak, men du kommer att bli överraskad över vilken skillnad det kan göra.

Git har integritet

För allt i Git beräknas en checksumma innan det lagras och sedan refererar man till denna checksumma. Detta betyder att det är omöjligt att ändra innehållet i någon fil eller katalog utan att Git känner till det. Denna funktionalitet är inbyggt i Git på de lägsta nivåerna och är fundamentalt för dess filosofi. Du kan inte tappa information på vägen eller få en korrupt fil utan att Git kan detektera det.

Mekanismen som Git använder för att beräkna checksumman kallas för en SHA-1 hash. Det är en fyrtio tecken lång teckensträng som består av hexadecimala tecken (0-9 och a-f) och beräknas baserat på innehållet i en fil eller katalogstruktur i Git. En SHA-1 has ser ut ungefär såhär:

24b9da6552252987aa493b52f8696cd6d3b00373

Du kommer att se dessa hashvärden överallt i Git, eftersom Git använder dem så mycket. I själva verket refererar Git till hashsumman av en fils innehåll i sin databas, och inte filnamnet.

Git lägger oftast bara till data

När du gör något i Git så resulterar detta alltid i att något läggs till i Gits databas. Det är svårt att få systemet att göra något som inte kan ångras, eller att ta bort data på något sätt. Som med vilket versionshanteringssystem som helst, kan du förlora eller förstöra ändringar som du ännu inte förbundit, men väl efter att en ögonblicksbild har förbundits är det svårt att förlora den, speciellt om du regelbundet skickar dina ändringar vidare till ett annat förvar.

Detta gör att det är kul att använda Git, eftersom vi vet att vi kan experimentera utan någon som helst fara för att ställa till saker och ting. För en mer ingående beskrivning över hur Git hanterar sin data och hur du kan återskapa det som verkar vara förlorat, se Undoing Things.

De tre tillstånden

Var nu uppmärksam — detta är de huvudsakliga delarna som du måste komma ihåg om Git om du vill att resten av inlärningsprocessen skall gå smärtfritt. Git har tre huvudsakliga tillstånd som dina filer kan vara i: förbundna, modifierade, och förberedda:

  • Förbunden (eng. commited) betyder att datan är säkert sparad i din lokala databas.

  • Modifierad (eng. modified) betyder att du har ändrat i filen, men att ändringarna inte är lagrade i din databas ännu.

  • Förberedd (eng. staged) betyder att du har valt en modifierad fil i sin nuvarande version för att ingå i din nästa förbindelse.

Detta leder oss till tre huvuddelar av ett Gitprojekt: Gitkatalogen, arbetsträdet och den förberedda ytan.

Arbetsträdet, stageingytan och Gitkatalogen.
Figure 6. Arbetsträdet, den förberedda ytan och Gitkatalogen.

Gitkatalogen är där Git lagrar metadata och objektdatabasen för ditt projekt. Detta är den viktigaste delen av Git och det är denna du kopierar om du klonar ett förvar från en annan dator.

Arbetsträdet är en enstaka utcheckning av en version av projektet. Dessa filer hämtas från den komprimerade databasen i Gitkatalogen och placeras på disken så att du kan använda eller modifiera dem.

Den förberedda ytan är en fil, generellt inuti din Gitkatalog, som sparar information om vad som skall ingå i din nästa förbindelse. Dess tekniska namn på Gitspråk är “index”, men “förberedda ytan” fungerar lika bra.

Det huvudsakliga arbetsflödet i Git liknar detta:

  1. Du modifierar filer i ditt arbetsträd.

  2. Du väljer selektivt ut de ändringar som skall ingå i din nästa förbindelse, och endast de ändringarna läggs till den förberedda ytan.

  3. Du gör en förbindelse, som tar ändrigarna i den förberedda ytan och sparar den ögonblicksbilden permanent till din Gitkatalog.

Om en specifik version av en fil finns i Gitkaltalogen, är den att anse som förbunden. Om den har modifierats och lagts till den förberedda ytan, är den förberedd. Om om den har ändrats efter att den checkats ut, men inte har förberetts är den modifierad. I Git Basics, kommer du lära dig mer om dessa olika tillstånd och hur du antingen kan dra nytta av dem eller skippa den förberedda ytan helt.