Versionskontroll med Git – ett oumbärligt verktyg för utvecklare

Föreställ dig att du arbetar i veckor på ett projekt, gör en ändring – och plötsligt slutar allt fungera. Utan versionskontroll kan det kännas som att leta efter en nål i en höstack. Git löser just det problemet. Som världens mest använda versionskontrollsystem hjälper Git utvecklare att spåra ändringar, samarbeta i team och enkelt återgå till tidigare versioner av koden. Oavsett om du är nybörjare eller erfaren utvecklare är Git ett verktyg du helt enkelt inte kan vara utan. I den här artikeln går vi igenom vad Git är, hur det fungerar och varför det har blivit en självklar del av modern mjukvaruutveckling.

Vad är Git och hur fungerar det i praktiken?

Git är ett distribuerat versionskontrollsystem som skapades av Linus Torvalds år 2005. Målet var att lösa ett konkret problem: hur hanterar man kodändringar i ett stort projekt med många inblandade utan att det blir kaos? Svaret blev ett system som inte bara sparar filer, utan hela historiken bakom dem. I dag används Git av miljontals utvecklare världen över och är en självklar del av professionell mjukvaruutveckling.

Hur Git tänker på data

Det som skiljer Git från många andra system är hur det lagrar information. Istället för att spara skillnaden mellan versioner tar Git ett slags ögonblicksfoto av hela projektet varje gång du sparar en förändring. Dessa ögonblicksbilder kallas commits och bildar tillsammans en tidslinje över projektets hela historia. Det innebär att du när som helst kan resa bakåt i tiden och se exakt hur koden såg ut vid ett visst tillfälle.

Distribuerat – vad betyder det egentligen?

Till skillnad från äldre system där all historik lagras på en central server har varje användare i Git en fullständig kopia av hela projektet lokalt på sin dator. Det betyder att du kan arbeta, spara commits och bläddra i historiken helt utan internetuppkoppling. Först när du vill dela ditt arbete med andra behöver du kontakta en fjärrserver, till exempel GitHub eller GitLab.

Det distribuerade upplägget ger flera fördelar. Om servern skulle gå ner finns hela historiken kvar hos varje utvecklare. Arbetet kan fortsätta utan avbrott och risken för att data går förlorad minskar drastiskt.

Centrala begrepp du möter direkt

För att förstå hur Git fungerar i vardagen behöver du känna till några grundläggande termer. De dyker upp redan från första stund och återkommer hela tiden i dokumentation, handledningar och kollegors konversationer.

Här är de begrepp du behöver ha koll på från början:

• Repository: Projektmappen som innehåller all kod och dess historik.
• Commit: En sparad förändring med ett tillhörande meddelande.
• Branch: En parallell arbetslinje där du kan utveckla utan att störa huvudkoden.
• Merge: Sammanfogningen av två branches till en.
• Clone: En lokal kopia av ett befintligt repository.

Staging-området – ett smart mellanlager

Innan en commit skapas passerar förändringarna genom något som kallas staging-området. Det fungerar som en förberedelsezon där du väljer precis vilka ändringar som ska ingå. Det ger dig möjlighet att dela upp arbete i logiska delar och skriva tydliga, beskrivande commit-meddelanden. En tumregel är att varje commit ska representera en enda förändring med ett tydligt syfte. Det gör historiken lättare att läsa och felsökning betydligt smidigare.

Grundläggande kommandon som varje utvecklare bör kunna

Git används främst via terminalen, och även om det finns grafiska verktyg är det en stor fördel att känna till de viktigaste kommandona. De ger dig full kontroll och förståelse för vad som faktiskt händer under ytan. När du väl lärt dig dem sitter de i ryggmärgen och du kommer använda dem dagligen utan att behöva tänka efter.

Komma igång med ett projekt

Det första du gör när du startar ett nytt projekt är att initiera ett repository. Det sker med kommandot git init, vilket skapar en dold mapp i din projektmapp där all historik lagras. Arbetar du istället med ett befintligt projekt som ligger på en fjärrserver använder du git clone följt av projektets adress. Då får du en fullständig lokal kopia av allt, inklusive hela historiken.

Spara förändringar på rätt sätt

När du gjort ändringar i koden är det dags att spara dem. Först lägger du till dem i staging-området med git add, antingen fil för fil eller alla på en gång. Därefter skapar du en commit med git commit och ett meddelande som beskriver vad du gjort. Ett bra commit-meddelande är kort men informativt. Det ska gå att förstå vad som förändrades utan att behöva öppna koden.

Här är de kommandon du återkommer till mest i det dagliga arbetet:

• git init: Skapar ett nytt lokalt repository.
• git clone: Laddar ner en kopia av ett befintligt repository.
• git add: Lägger till filer i staging-området.
• git commit: Sparar de förberedda förändringarna med ett meddelande.
• git status: Visar vilka filer som ändrats eller väntar på att committas.
• git log: Visar hela commit-historiken för projektet.

Synkronisera med en fjärrserver

När du arbetar i ett team eller vill säkerhetskopiera din kod på en plattform som GitHub behöver du synkronisera din lokala kod med en fjärrserver. Det görs med två kommandon. Git push skickar dina lokala commits till servern, och git pull hämtar andras förändringar till din maskin. Det är klokt att köra git pull innan du börjar arbeta varje dag för att säkerställa att du alltid har den senaste versionen av koden.

När något går fel

Förr eller senare gör alla misstag. Kanske committade du fel fil eller skrev ett dåligt meddelande. Git har inbyggda sätt att hantera det. Med git revert kan du ångra en specifik commit utan att radera historiken. Det är ett säkrare alternativ än att försöka skriva om det som redan sparats, särskilt när du arbetar tillsammans med andra i samma kodbas.

Git i team – samarbete med branches och pull requests

En av Gits absoluta styrkor är hur väl det hanterar samarbete. När flera utvecklare arbetar på samma kodbas samtidigt uppstår snabbt konflikter om inte arbetet struktureras rätt. Git löser detta genom ett förgreningssystem som låter varje person arbeta i sin egen isolerade miljö utan att störa andras arbete. Det är ett arbetssätt som används av allt från små startups till stora teknikbolag.

Vad är en branch och varför ska du använda den?

En branch är en parallell version av koden där du kan experimentera, utveckla nya funktioner eller fixa buggar utan att röra huvudkoden. Som standard finns en branch kallad main, eller tidigare master, som representerar den stabila versionen av projektet. Varje gång du påbörjar något nytt skapar du en ny branch, arbetar klart och sammanfogar den sedan tillbaka till main när allt fungerar som det ska.

Det är ett tryggt arbetssätt som minimerar risken för att halvfärdig kod tar sig in i produktionen. Du kan till och med ha flera branches aktiva samtidigt och växla fritt mellan dem.

Merging och hur konflikter hanteras

När en branch är klar sammanfogas den med main genom en merge. I många fall sker detta automatiskt och utan problem. Men om två personer har ändrat samma del av samma fil uppstår en så kallad merge-konflikt. Git markerar då exakt var konflikten finns och låter dig manuellt välja vilken version som ska behållas. Det kan kännas ovant första gångerna, men med lite erfarenhet är det ett hanterbart och tydligt system.

Pull requests – kodgranskning i praktiken

På plattformar som GitHub och GitLab sker sammanfogningen ofta via något som kallas en pull request. Det är en begäran om att få slå ihop sin branch med huvudkoden, och den fungerar samtidigt som ett tillfälle för kollegor att granska förändringarna innan de godkänns. Det är här mycket av det faktiska samarbetet sker, i form av kommentarer, förslag och diskussioner direkt kopplade till koden.

Pull requests bidrar till högre kodkvalitet och är ett utmärkt sätt för mindre erfarna utvecklare att lära sig av mer seniora kollegor. Många team har som rutin att minst en person alltid granskar en pull request innan den mergas.

Ett gemensamt språk för hela teamet

Att arbeta med Git i team handlar till stor del om att etablera gemensamma rutiner. Hur döper ni era branches? Hur ska ett commit-meddelande formuleras? Hur ofta pushar ni? Dessa frågor kan verka små men gör stor skillnad i längden. Ett team som följer tydliga konventioner sparar tid, minskar friktionen och håller kodbasen i gott skick över tid.