1.3 Kom igång - Vad är Git?

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).

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 sparar en version 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 effektivisera 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

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 förgreningar.

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 filändringar mellan nuvarande version av filen och för en månad sedan, kan Git ta 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 spara versioner gladeligen (till din lokala kopia, eller hur?) tills du får tillgång till en nätverksanslutning för att skicka dina versiner. 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.

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:

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.

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 Ångra saker.

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: sparade, modifierade, och preparerad:

Detta leder oss till tre huvuddelar av ett Gitprojekt: Gitkatalogen, arbetsträdet och den prepareringsytan.

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.

Prepareringsytan är en fil, generellt inuti din Gitkatalog, som sparar information om vad som skall ingå i din nästa version. Dess tekniska namn på Gitspråk är “index”, men “prepareringsytan” fungerar lika bra.

Det huvudsakliga arbetsflödet i Git liknar detta:

Om en specifik version av en fil finns i Gitkatalogen, är den att anse som sparad. Om den har modifierats och lagts till prepareringsytan, är den preparerad. Om om den har ändrats efter att den checkats ut, men inte har preparerats är den modifierad. I Grunder i Git, kommer du lära dig mer om dessa olika tillstånd och hur du antingen kan dra nytta av dem eller skippa prepareringsytan helt.