Göm meny
Gäller för: HT23

Git

Versionshanteringssystem

Git är ett populärt, distribuerat versionshanteringssystem (DVCS, Distributed Version Control System). Ett versionshanteringssystem (VCS, Version Control System) är vad det låter som; ett system för att hantera olika versioner av filer. Syftet är att göra det lätt att prova lösningar, ångra sig, backa tillbaka till tidigare versioner etc.

Tidigare versionshanteringssystem som t.ex. CVS eller SVN (Subversion) byggde på att det fanns ett centralt repository från vilket användare hämtade (check out) filer som de skulle jobba med och sedan skickade in (commit) när ändringen var genomförd.

Idag är versionshanteringssystemen distribuerade, d.v.s. att det inte behöver finns en central nod som alla hämtar och lämnar filer till. Git, Mercurial och Bazaar är mest använda systemen, men av dessa är Git det mest använda.

Användning av git på kursen

Att använda eller inte använda Git är fritt upp till er. Det kan fungera som ett sätt för er att dela med er av kod inom er pargrupp. Inte alla assistenter har erfarenhet av att använda Git, men många har det. Ett alternativa sätt att dela med er av kod med varandra är att ha en delad mapp i er OneDrive.

En översikt över de viktigaste begreppen i Git

  • git add: Alla filer i vår working directory behöver inte versionshanteras. För att en fil ska versionshanteras behöver vi berätta det för git. Detta gör vi genom att använda kommandot git add <fil/er>.
  • branch: en utvecklingsgren. I git kan vi snabbt växla mellan olika branches i vår arbetskatalog. Branches används t.ex. för att skilja på vad som är en släppt version av koden och vad som är under utveckling. Typisk används också branches av utvecklare för att jobba på en förbättring av koden lokalt. När man tror att man är klar så pushar man upp sin branch och gör en merge-request, dvs säger “nu är jag klar med min utveckling, här är filerna, kan du kolla igenom och godkänna ihopslagning med master”.
  • checkout: Vi använder git checkout för att hämta ut eller byta till en specifik branch eller commit från repot.
  • clone: Vi använder git kommandot git clone för att
  • commit: commit används både som verb “vi gör en commit” och som substantiv för att referera till en specifik commit i repot. I Git och många andra DVCS:er hanteras versioner inte på fil-nivå, utan på repo-nivå. Vi checkar ut en specifik commit och vi får ut alla filer. När vi commit:ar något väljer vi en eller fler filer som ska ingå i den commit:en. När vi gör en commit säger vi alltså endast vilka filer som ändrats, men när vi checkar ut en specifik commit får vi alla filer som de var just då, inte bara de som ingick i själva commit:en.
  • GitHub, GitLab: Både GitHub och GitLab är en webbaserad tjänster som låter dig lägga upp dina repon på webben. Integrerat finns bl.a. ärendehantering (issue-tracking), wiki för dokumentation m.m. Gitlab är ett exempel på en liknande webbaserad tjänst. GitLab är open source och LiU har en egen GitLab-server som ni kan använda: https://gitlab.liu.se
  • merge: Vi kan slå ihop t.ex. olika commits (som t.ex. gjorts av olika användare på olika ställen) eller olika branches (t.ex. vår utvecklingsbranch, som ofta döps till dev med master)
  • remote/remote repository: Hänvisar till ett repo som inte är lokalt. Vi kan lägga till flera remotes till lokalt git-repo, men många gånger har man bara ett.
  • repository: Många säger “repo” på både svenska och engelska. Ett repo är delen av systemet som håller koll på vilka filer, branches, versioner som finns
  • working directory: utcheckad katalog som innehåller filer för en specifik version av repot.

Exempel på typisk användning av Git med en onlinetjänst

Nedanstående är ett exempel. Git är väldigt flexibelt och det går att göra saker på väldigt många olika sätt. För att göra texten mer lättläst kommer jag låtsas som att detta är det “enda” sättet, men det är det absolut inte.

Man kan också jobba helt lokalt, dvs utan ett remote repo. Vi kan då jobba med versioner på vår lokala dator, skapa branches etc utan att ha något i “molnet”. Läs exemplet som en översiktlig och orienterande beskrivning av ett arbetsflöde. Mer information om kommandon etc. får du läsa i andra resurser.

Vi skapar ett repo på GitLab och klonar sedan det med git clone så att vi har en lokal kopia av repositoryt. När vi klonar repot checkar vi även automatiskt ut branchen master. Den klonade katalogen är egentligen vår arbetskatalog (working directory) och själva repot finns i mappen .git som återfinnes i arbetskatalogen.

Jag redigerar min kod i filer som läggs i arbetskatalogen. När jag vill spara en version av systemet berättar jag för git vilka filer som ska läggas till min commit och sedan gör jag en commit.

För att min kompis ska kunna ta del av den version jag precis committat, gör jag en git push till repot på GitLab, en remote repository. Min kompis kör sedan en git pull hos sig och för att hämta uppdateringen. Git klarar av att slå ihop ändringar som gjorts remote och lokalt, men ibland går det inte och då får man en konflikt som man behöver lösa genom att säga exakt hur filen ska se ut. För att undvika detta är det bäst att kommunicera med varandra och säga vilka filer man jobbar i.

Använda git via terminal eller via ett GUI-verktyg?

Det finns många grafiska gränssnitt för att använda Git. Dessa gör det lätt att använda Git utan att egentligen förstå vad man gör. Jag rekommenderar att ni använder git via terminalen eftersom det hjälper er förstå arbetsflödet och begreppen; eller snarare det tvingar er till att förstå begreppen. Det är inte särskillt många som behövs för enklare användning av git.

Ett grafiskt gränssnitt gör väldigt mycket väldigt tillgängligt och det är lätt hänt att man gör saker utan att vet vad man egentligen gör vilket kan orsaka problem.

Vanliga saker man kan vilja göra

Kommandona i git är väldigt flexibla vilket är både en fördel och en nackdel. I de flesta fallen kan man göra mycket mer med de kommandon som gås igenom nedan genom att lägga till diverse flaggor.

Klona ett repo

Använd git clone <URL> för att klona ett repo. Repot kommer klonas till en mapp som har samma namn som repot och med branchen master utcheckad.

Återställa en specifik fil till dess senaste commit

För att återställa en specifik fil till hur den såg ut i den senaste commit:en använd

git checkout <sökväg till fil>

Om din fil heter samma sak som en branch behöver du använda

git checkout -- <sökväg till fil>

Skapa en ny branch lokalt

Använd git checkout -b <namn på branch> för att skapa en ny branch och checka ut den.

Byta till en branch

Använd git checkout <namn på branch> för att byta till en specifik branch.

Slå ihop en branch med en annan, t.ex. dev med master

Säg att vi vill föra tillbaka ändringar från vår branch dev till master. Det vi gör då är att först checka ut master och anger sedan vilken branch vi vill merga in i master:

$ git checkout master
$ git merge dev

Några resurser


Sidansvarig: Johan Falkenjack
Senast uppdaterad: 2024-07-26