Git och versionshantering: hur svenska team jobbar med kod

Inget modernt svenskt IT-företag – oavsett om det är en global jätte som Klarna och Ericsson, eller en nystartad designbyrå i Malmö – kan fungera utan strukturerad versionshantering. Mjukvaruutveckling är idag en utpräglad lagsport. Fem, femtio eller femhundra utvecklare kan behöva skriva kod i samma system samtidigt, utan att förstöra för varandra. För att hantera detta kaos används verktyget Git. Men att förstå kommandona i Git är bara ena halvan av sanningen. För att lyckas i Sverige måste du också förstå kulturen kring hur Git används: från Pull Requests till den extremt viktiga, svenska, skamfria arbetsmiljön.

Git och Förrådet (Repository)

Git är ett distribuerat versionshanteringssystem. Det spårar varje enskild ändring som görs i en fil. Hela företagets kodbas ligger lagrad i ett digitalt förråd, ett Repository (ofta förkortat "repo"), vanligtvis hostat i molnet hos GitHub, GitLab eller Bitbucket.

När du börjar din arbetsdag i Sverige, klonar du ner (kopierar) repot till din egen dator. Den stabila koden – den som kunderna faktiskt använder – ligger i en huvudgren som kallas main (tidigare ofta kallad master). Du får aldrig koda direkt i main. Istället skapar du en förgrening, en Branch. Detta är din egen sandlåda. Här kan du testa nya idéer, bygga din funktion och till och med krascha applikationen, utan att det påverkar någon annan på företaget.

Arbetsflöden: GitFlow vs Trunk-Based Development

Svenska arbetsplatser präglas ofta av struktur och metoder. Historiskt har många använt ett arbetssätt som kallas GitFlow. Det innebär att man har många olika grenar (exempelvis en för utveckling, en för test och en för produktion) och funktionen flyttas försiktigt mellan dessa. Detta ger enorm trygghet men är ofta långsamt.

De senaste åren har svenska startups, i sin jakt på extrem effektivitet och snabbhet, rört sig mer mot Trunk-Based Development. Här hålls grenarna extremt kortlivade. En utvecklare bygger en liten funktion och slår snabbt ihop den (via en Merge) med huvudgrenen, ibland flera gånger om dagen. Detta kräver dock att företaget har ett enormt starkt skyddsnät av automatiska tester för att förhindra att buggar når kunden.

Kodgranskning och Pull Requests (PR)

När du är klar med din kod på din branch, och vill föra in den i huvudgrenen, skapar du en Pull Request (ofta förkortat PR, eller Merge Request i GitLab). Här möter vi den svenska konsensuskulturen i teknisk form. En PR är en formell förfrågan: "Jag har skrivit den här koden, snälla teamet, kan ni granska och godkänna den?"

Det förväntas alltid att minst en, ofta två, kollegor gör en kodgranskning (Code Review). De läser din kod rad för rad. Syftet är tvådelat: att hitta fel innan koden går live, men också att dela kunskap inom teamet. I Sverige är kodgranskningar sällan aggressiva eller dömande. En senior utvecklare kommer inte skriva "Den här funktionen är skräp, gör om". De kommer snarare skriva: "Bra jobbat! Jag tänkte dock på den här loopen – tror du vi skulle kunna optimera den för att spara minne? Vad tänker du om det?" Den inlyssnande, coachande tonen är ständigt närvarande. Kritik ges alltid på ett konstruktivt och respektfullt sätt.

Hantering av Konflikter (Merge Conflicts)

Ibland uppstår en Merge conflict (sammanslagningskonflikt). Detta händer när du och en kollega har redigerat exakt samma rad i samma fil, och Git inte vet vems kod som ska sparas. I många miljöer kan detta orsaka panik. I Sverige hanteras det med ett kaffemöte. Ni sätter er ner (kanske via skärmdelning på Teams), tittar på konflikten och kommer överens om hur ni bäst kombinerar lösningarna. Det är ingen tävling om vems kod som ska "vinna"; målet är att den slutgiltiga koden ska vara så bra som möjligt för användaren.

Den skamfria kulturen (Blame-free culture)

Trots PR:s och tester kommer det hända att en bugg når produktionen och kraschar hemsidan. Git har ett underbart kommando som heter `git revert`, vilket snabbt rullar tillbaka koden till hur den såg ut igår, och skadan är minimerad.

Men det unika är vad som händer efter kraschen. I många länder startas en häxjakt för att hitta vem som orsakade felet och skälla ut den personen (eller rentav avskeda hen). I Sverige använder vi oss av en skamfri kultur (Blame-free culture). När kraschen är löst håller man ofta ett möte, en så kallad Post-mortem. Man letar inte efter VEM som gjorde fel, man letar efter HUR systemet lät felet hända. Frågan är: "Hur kunde vår kodgranskning eller våra automatiska tester missa detta? Vad måste vi bygga för att förhindra att det händer en annan kollega imorgon?"

Sammanfattning

När du arbetar i ett svenskt IT-team är Git ditt viktigaste verktyg. Men kom ihåg: din förmåga att använda Git handlar inte bara om att kunna terminalkommandona utantill. Det handlar om att förstå att varje Pull Request är ett samtal, varje kodgranskning är en möjlighet att lära sig, och varje misstag du rullar tillbaka är en chans att göra det gemensamma systemet starkare och säkrare.