Git — vad är det, arbetsprinciper och kommandon

Vad är Git?

Git — är ett distribuerat versionshanteringssystem (VCS) som spårar ändringar i filer och tillåter flera utvecklare att arbeta samtidigt på samma projekt. Till skillnad från centraliserade system har i Git varje utvecklare en fullständig kopia av arkivet, inklusive hela ändringshistoriken, vilket gör systemet motståndskraftigt mot dataförlust och kräver ingen konstant anslutning till den centrala servern.

Historien om Git började 2005 när Linus Torvalds skapade ett nytt VCS efter att BitKeeper-företaget drog tillbaka den kostnadsfria licensen för sitt system för Linux-kärnutvecklare. Målen var: hastighet, arkitekturens enkelhet, stöd för icke-linjär utveckling genom grenar och fullständig distribution. På 3 månader skrev Torvalds kärnan av Git, och efter ett år övergick projektet till självförvaltning under ledning av Junio Hamano.

Enligt Stack Overflow-undersökningen (2024) använder 93,9% av professionella utvecklare Git, vilket gör det till det dominerande versionshanteringssystemet i branschen. Den närmaste konkurrenten — Subversion (SVN) — används endast i 5,2% av projekten, främst i stora företagsmiljöer med centraliserade processer.

Hur fungerar Git: arkiv och committar

Git-arkiv — är en katalog där Git spårar ändringar av alla filer. Inuti katalogen finns en dold mapp .git där alla systemobjekt lagras: committar, träd, blobbar och referenser. När en utvecklare skapar en commit kopierar Git inte filerna i sin helhet — det skapar en ögonblicksbild (snapshot) av tillståndet och sparar en referens till den.

Varje commit innehåller: en unik SHA-1-hash (40 tecken), en referens till föregående commit (parent), författare, datum, commit-meddelande och en referens till trädet (tree) som beskriver filernas tillstånd vid commit-tillfället. Kedjan av committar bildar en riktad acyklisk graf där varje commit pekar på en eller flera föräldrar.

# Initiera arkiv
git init my-project
cd my-project

# Skapa commit
echo "Hello, Git" > README.md
git add README.md
git commit -m "Initial commit"

# Visa historik
git log --oneline --graph --all

Git använder tre huvudområden: working directory (filer på disken), staging area (index där förberedda filer hamnar) och repository (commithistorik). Kommandot git add flyttar ändringar från arbetskatalogen till staging, och git commit registrerar staging-innehållet i arkivet. Denna uppdelning gör det möjligt för utvecklaren att samla en meningsfull commit från en uppsättning ändringar utan att registrera varje korrigering separat.

Grundläggande Git-kommandon

Grundläggande Git-kommandon täcker 90% av utvecklarens dagliga operationer. Kommandot git clone skapar en lokal kopia av ett fjärrarkiv, git pull hämtar ändringar från servern och slår samman dem med den aktuella grenen, och git push skickar lokala committar till servern. Dessa tre kommandon utgör den grundläggande arbetscykeln med Git.

För att visa status används git status — den visar vilka filer som har ändrats, vilka som har lagts till i staging och vilka som inte spåras. git diff visar konkreta ändringar i filer innan de läggs till i staging. Nedan finns en tabell med de mest använda kommandona:

För att ångra ändringar erbjuder Git flera alternativ. git reset flyttar grenpekaren till en angiven commit och kan återställa staging eller arbetskatalogen. git revert skapar en ny commit som ångrar ändringarna från en angiven commit — detta är ett säkert sätt att ångra för delade grenar eftersom historiken inte skrivs om.

Grenar i Git: main, feature och release

Grenar i Git — är lätta flyttbara pekare till en specifik commit. Att skapa en ny gren kopierar inte filer, utan skapar bara en ny pekare, vilket gör grenarbete praktiskt taget omedelbart. Grenen main (tidigare master) — projektets huvudgren som innehåller stabil, redo för release-kod.

Standardpraxis är att använda Git Flow eller GitHub Flow. I Git Flow används grenar: main (releasekod), develop (integrationsgren), feature/* (nya funktioner), release/* (releaseförberedelser) och hotfix/* (akuta korrigeringar). GitHub Flow är enklare: bara main och feature-grenar, och alla ändringar levereras via Pull Request.

# Skapa och växla gren
git branch feature-auth
git checkout feature-auth
# eller med ett kommando:
git checkout -b feature-auth

# Lista grenar
git branch --list
git branch -a  # alla grenar, inklusive fjärrgrenar

# Ta bort gren
git branch -d feature-auth

En viktig egenskap hos Git-grenarbete — möjligheten till cherry-pick: överföring av en enskild commit från en gren till en annan med kommandot git cherry-pick <hash>. Detta är användbart när du behöver överföra en buggfix från en feature-gren till release utan att slå samman hela grenen. Git stöder också rebase och interaktiv rebase (git rebase -i) för att limma ihop, ordna om och redigera committar.

Sammanfogning: Merge och Rebase

Merge (sammanfogning) skapar en speciell merge-commit som har två föräldrar. Denna commit registrerar faktumet att två grenar slagits samman och bevarar fullständig historik — det syns var och när sammanfogningen skedde. Merge bevarar historiken i den form den skapades, vilket förenklar granskning men gör commit-grafen mer komplex.

Rebase (ombasering) istället för att skapa en merge-commit flyttar committarna från den aktuella grenen till toppen av mål-grenen. Historiken blir linjär — det skapas intrycket att utvecklingen skedde sekventiellt. Rebase skriver dock om historiken och ändrar SHA-1-hasharna för committarna, vilket gör det farligt för delade grenar som andra utvecklare har tillgång till.

Rekommendation för val: använd merge för publika grenar där historiken ses av andra utvecklare (feature → develop), och rebase för lokalt arbete när du behöver tillämpa färska ändringar från main i din feature-gren innan du skapar en Pull Request. Regeln är enkel: om en commit redan har skickats till servern — ombasera den inte.

Lösa konflikter

Sammanfogningskonflikt uppstår när Git inte automatiskt kan kombinera ändringar i en fil. Git markerar konfliktområden i filen med speciella markörer: <<<<<<< (våra ändringar), ======= (avgränsare), >>>>>>> (deras ändringar). Utvecklaren redigerar filen manuellt, väljer önskat alternativ eller kombinerar båda, och slutför sammanfogningen med en commit.

Arbeta med fjärrarkiv

Fjärrarkiv (remote) — en kopia av Git-arkivet som finns på en server. GitHub, GitLab och Bitbucket är de mest populära plattformarna för att hosta fjärrarkiv. De tillhandahåller ett webbgränssnitt för att visa kod, åtkomsthantering, kodgranskning och integration med CI/CD-system.

I Git kan flera fjärrarkiv konfigureras för ett projekt. Som standard heter det huvudsakliga remote origin. Kommandot git remote add lägger till ett nytt remote, git fetch hämtar ändringar utan sammanfogning, och git pull är en förkortning för git fetch + git merge. För att arbeta med kod via Pull Request skapar utvecklaren en fork av arkivet, klonar det, arbetar i en feature-gren och skickar en sammanfogningsbegäran till det ursprungliga arkivet.

# Lägg till fjärrarkiv
git remote add origin https://github.com/user/repo.git

# Visa fjärrarkiv
git remote -v

# Skicka gren till servern
git push -u origin feature-auth

# Hämta ändringar från fjärrgren
git pull origin main

Fjärrarkiv stöder tagging för att markera release-versioner. Taggar kan vara lätta (bara en pekare till en commit) och annoterade (innehåller metadata: författare, datum, meddelande). Annoterade taggar rekommenderas för release-versioner eftersom de överför fullständig information om versionen och kan signeras med en GPG-nyckel för verifiering av författarskap.

Git Worktree för parallellt arbete

Git Worktree gör det möjligt att samtidigt arbeta med flera grenar i olika kataloger utan att växla mellan dem. Kommandot git worktree add ../feature-auth feature-auth skapar en ny arbetskatalog feature-auth där kod kan skrivas utan att byta gren i huvudkatalogen. Worktree är användbart för snabba korrigeringar i release-grenen när huvudkatalogen är upptagen med långsiktig utveckling.

Git Submodules för beroenden

Git Submodules — en mekanism för att inkludera ett Git-arkiv i ett annat. Submodulen lagrar en referens till en fast commit av ett externt arkiv, vilket garanterar repeterbarhet av bygget. Kommandot git submodule add https://github.com/example/lib.git lägger till ett externt bibliotek som en submodul. Vid kloning av ett projekt med submoduler måste git submodule update --init --recursive köras för att ladda alla beroenden.