Git på insidan

Efter att jag hållit ett föredrag om revisionshanteringssystem blev jag inspirerad att även hålla ett Lunch-n-Learn föredrag om Git. Jag insåg dock snart att även om jag jobbat mycket med Git hade jag inte så stor koll på vad som händer på insidan. Efter lite googlande insåg jag att det var ett vanligt problem och att vissa verkar anse att Git, som skapats av Linus Torvalds inte riktigt designats för oss vanliga dödliga, eller som sägs i inledningen i hans tal på Google, “[Linus Torvalds] latest act of cruelty is to create a revision control system expressly designed to make you feel less intelligent then you though you where”.

Efter lite mer googlande hittade jag dock en förträfflig föreläsning av Michael Schwern som heter Git For Ages 4 And Up. Michael använder Tinkertoys för att visa hur Git bygger upp en riktad acyklisk graf och gör på ett sätt som gör det enkelt att förstå. Om du har tid så se presentationen så gör det! För alla ni andra, här är ett försök att göra samma sak med animationer i stället.

Orginalet till dessa animationer är mitt Google dokument från presentationen och det fungerar ärligt talat bättre då man kan klicka sig fram i sin egen takt men dessa fungerar bättre i en blogg.

## Grundläggande funktioner
Här visas hur man skapar, lägger till och “commitar” sina första filer samt gör en branch. Gula cirklar är noder som skapas i Git. När dom commitas får dom ett id, här bara ett tecken och inte den fulla SHA summan. Etiketter är rektanglar. Vald ettikett är blå och dom andra är gröna. HEAD etiketten är lite speciell (sätts alltid på den nod du har checkat ut och har färgen vit.
Värt att notera är att Git verkligen sparar något när du gör add, men det “syns” inte förän du gjort commit samt att en branch i Git inte är något mer än en etikett.

## Fast forward
Denna animation fortsätter från den förra. Vi har just checkat ut feature branchen och skapar sedan några ändringar. När man sedan vill merga dessa till Master letar Git efter minsta gemensamma nod id, f i detta fall. När detta hittas behöver Git bara jämföra efterföljande id för att inse att detta inte är en egentlig merge utan en fast forward. Detta görs enkelt genom att flytta etiketten framåt, snabbt och smärtfritt.
Notera att ett nod id är baserat på hela nodens innehåll samt dess förälders id. Således kan man med säkerhet säga att om man har två id med samma värde måste dom vara lika (då dom har samma föräldrar som också har samma föräldrar som också… osv).

## Merge
Om det inte går att göra en fast forward utför Git en “riktig” merge. Denna utförs enligt någon av Gits merge strategier och resulterar (till skillnad från en fast forward) i en ny nod.

## Clone och push
Nu lämnar vi lokal utveckling och tittar på en annan av Gits största styrkor, distribuerad revisionshantering. Git är designat för att göra det enkelt dela och ta del av kod. Varje repositorium som skapas (med git init eller git clone) är komplett och fristående. Detta innebär att du kan arbeta helt utan kontakt mot någon server. När du vill dela med dig av din kod pushar du dina ändringar och när du vill ta del av andra kod kan gör du fetch eller pull (som är en fetch och merge). Nedan visas clone och push. När man gör push använder Git sig av checksummorna för att hitta de noder som skiljer och skickar bara dessa, detta (tillsammans med komprimering) gör att Git inte behöver skicka så stora datamängder.
Notera att Git håller reda på etiketter i ursprungs repositoriet med med namnet /, dessa uppdateras vid en fetch.

Detta var lite grundläggande Git kommandon och hur dom hanteras av Git. För mer information kan man se filmen som länkas ovan eller läs i Git dokumentationen.

//Martin Wåger