Git och versionshantering i mobilutveckling: vad det är, grundläggande kommandon och hur det fungerar

Versionshantering och Git: vad är det?

Git är ett distribuerat versionshanteringssystem (VCS) skapat av Linus Torvalds 2005 för utveckling av Linux-kärnan. Till skillnad från centraliserade system (SVN, CVS) lagrar Git en fullständig kopia av projektets historik på varje utvecklares dator. Detta innebär att du kan göra commits, bläddra i historiken och skapa grenar även utan internetanslutning.

Git arbetar med ögonblicksbilder (snapshots) — varje commit sparar tillståndet för alla projektfiler vid sparningstillfället. Om en fil inte har ändrats skapar Git en referens till den tidigare versionen, vilket sparar utrymme. Enligt GitHub-analys (2025) innehåller det genomsnittliga repositoryt 1 200 commits och 15 grenar.

På IT Sectr har vi använt Git sedan 2017 i alla projekt. Vår erfarenhet visar att korrekt Git-konfiguration från första dagen sparar teamet upp till 30 % tid på sammanslagningar och konfliktlösning. Git har blivit de facto-standard — det stöds av alla moderna IDE (Android Studio, Xcode, VS Code) och CI/CD-system.

# Grundläggande Git-inställning
git config --global user.name "Ditt Namn"
git config --global user.email "din@email.com"

# Skapa ett nytt repository
git init my-project
cd my-project

# Lägga till filer och commit
git add README.md
git commit -m "Initial commit"

# Arbeta med ett fjärrrepository
git remote add origin https://github.com/user/my-project.git
git push -u origin main

Koden ovan visar den grundläggande sekvensen: initiera ett repository, första commit och publicering på en fjärrserver. Kommandot git init skapar en dold .git-mapp som lagrar hela projektets historik. Varje git commit skapar en återställningspunkt som du kan återgå till när som helst.

Grundläggande begrepp: Repository, Branch, Commit

Att förstå de tre grundläggande begreppen — Repository, Branch och Commit — är avgörande för att arbeta med vilket versionshanteringssystem som helst. Ett repository är en container för hela projektet. En commit är ett sparat tillstånd av filer. En branch är en separat utvecklingslinje.

Repository kan vara lokalt (på din dator) eller fjärranslutet (på en GitHub-, GitLab-server). Varje utvecklare klonar fjärrrepositoryt till sin maskin och arbetar med en lokal kopia. Ändringar synkroniseras via push (skicka) och pull (hämta). I distribuerad versionshantering lagrar varje utvecklare en fullständig kopia av historiken.

Branch (gren) är en pekare till en av commitsen. Grenar möjliggör parallell utveckling: en utvecklare arbetar på en ny funktion (feature branch), en annan fixar en bugg (hotfix branch), en tredje förbereder en release (release branch). Enligt GitLab Flow (2025) har det genomsnittliga projektet 3–5 aktiva grenar samtidigt.

Commit är en enhet av förändring. Varje commit innehåller en unik hash (SHA-1), ett meddelande, en författare och en tidsstämpel. God praxis är att göra små meningsfulla commits med beskrivande meddelanden — detta förenklar Code Review och återställning av ändringar. Versionshantering genom commits ger dig projektets fullständiga historik.

Feature Branch

Feature Branch (funktionsgren) är en tillfällig gren skapad från develop eller main för att utveckla en specifik uppgift. Efter att arbetet är klart slås grenen tillbaka via Pull Request och tas bort. Denna praxis gör det möjligt att isolera ändringar utan att påverka stabiliteten i huvudkodbasen.

Typiskt arbetsflöde: skapa gren feature/add-login → gör flera commits → skapa Pull Request → gå igenom Code Review → slå samman i develop. På IT Sectr använder vi precis detta tillvägagångssätt: varje Jira-uppgift motsvarar en separat funktionsgren. Detta förenklar spårning av ändringar och återställning vid behov.

Rebase vs Merge

Merge skapar en merge-commit som kombinerar två grenar. Den bevarar fullständig historik, inklusive parallella utvecklingslinjer. Rebase skriver om historiken: den tar commits från en gren och "applicerar om" dem ovanpå en annan, vilket skapar en linjär historik.

Merge är lämpligare för offentliga grenar och stora team där kronologi är viktig. Rebase är praktiskt för personliga funktionsgrenar innan du skapar en PR — det gör historiken renare och mer förståelig. Rebase bör dock aldrig tillämpas på grenar som andra utvecklare arbetar på, eftersom det skriver om historiken.

# Skapa och växla till en funktionsgren
git checkout -b feature/add-login main

# Arbeta i grenen
git add login-screen/
git commit -m "Add login screen layout"

# Rebase på senaste main före PR
git checkout main && git pull
git checkout feature/add-login
git rebase main

# Push till fjärrrepository
git push origin feature/add-login

Detta exempel visar ett typiskt arbetsflöde: skapa en funktionsgren från main, flera commits och rebase för att få en ren linjär historik innan sändning för granskning. Detta tillvägagångssätt minimerar sammanslagningskonflikter.

Git Flow vs Trunk-Based Development

Git Flow och Trunk-Based Development är två huvudstrategier för versionshantering som bestämmer hur ett team organiserar arbetet med Git. Valet beror på teamets storlek, releasefrekvens och stabilitetskrav.

Git Flow är en strikt modell med flera permanenta grenar: main (releasekod), develop (aktuell utveckling), feature/* (nya funktioner), release/* (releaseförberedelse) och hotfix/* (brådskande fixar). Denna modell är bra för projekt med tydliga releasecykler (t.ex. mobilappar med version 1.0, 2.0).

Trunk-Based Development är ett tillvägagångssätt med en enda huvudgren (trunk/main) där alla utvecklare slår samman ändringar flera gånger om dagen. Feature-flaggor används för att dölja ofullständiga funktioner. Detta tillvägagångssätt är populärt inom webbutveckling och startups där leveranshastighet är viktig.

Git Flow

Git Flow, föreslaget av Vincent Driessen 2010, förblir en av de mest populära modellerna. Dess främsta fördel är strikt separation av kod efter livscykelstadier. Grenen main innehåller endast releasekod, develop innehåller aktuell utveckling och funktionsgrenar isolerar nya funktioner från varandra.

Hotfix-grenar skapas från main för brådskande fixar och efter sammanslagning slås de tillbaka till både main och develop. Release-grenar skapas från develop när teamet är redo för en release. Endast buggfixar och metadata (version, build) läggs till dem. Eter releasen slås release-grenen samman i main och develop. Enligt en JetBrains-undersökning (2024) använder 37 % av teamen Git Flow. Denna versionshanteringsmodell förblir standarden för projekt med fasta releaser.

# Git Flow exempel: påbörja arbete på en release
git checkout -b release/1.2.0 develop

# Fixa buggar i release-grenen
git commit -m "Fix login button crash"

# Slutför releasen — slå samman i main och develop
git checkout main
git merge --no-ff release/1.2.0
git tag -a 1.2.0

git checkout develop
git merge --no-ff release/1.2.0

# Ta bort release-grenen
git branch -d release/1.2.0

Koden illustrerar skapandet av en release-gren, dess stabilisering och sammanslagning i huvudgrenarna. Flaggan --no-ff garanterar en merge-commit, vilket bevarar informationen att ändringarna kom från release-grenen.

Pull Request och Code Review

Pull Request (PR) är en mekanism genom vilken en utvecklare föreslår ändringar från sin gren till huvudgrenen. PR är en nyckelkomponent i versionshantering i teamarbete — det är inte bara ett sätt att slå samman kod, utan en process för diskussion, granskning och kvalitetskontroll. I GitLab kallas den liknande mekanismen Merge Request (MR), men innebörden är densamma: informera teamet om ändringar och få godkännande.

En bra PR bör vara liten (upp till 300 rader kod), fokuserad på en enda uppgift och innehålla en beskrivning av vad som gjorts och varför. Enligt en Google-studie (2025) tar PR över 400 rader dubbelt så lång tid att granska och sannolikheten att upptäcka buggar minskar med 30 %. Code Review är granskning av kod av en annan utvecklare före sammanslagning.

På IT Sectr tillämpar vi obligatorisk Code Review för varje PR. Detta förbättrar inte bara kodkvaliteten utan hjälper också till att sprida kunskap inom teamet. Code Review kontrollerar: om koden följer arkitekturprinciper, om det finns buggar, om det finns tillräckligt med tester, om variabler är korrekt namngivna. Alla kommentarer diskuteras i PR tills sammanslagning.

Plattformar: GitHub, GitLab, Bitbucket

Git är ett protokoll, men för samarbete behövs en versionshanteringsplattform som tillhandahåller webbgränssnitt, åtkomsthantering, CI/CD och granskningsverktyg. Tre plattformar dominerar marknaden: GitHub, GitLab och Bitbucket.

GitHub är den största plattformen med över 56 miljoner utvecklare. Ägs av Microsoft och erbjuder Actions (CI/CD), Pages (hosting), Discussions och Copilot. Den kostnadsfria planen inkluderar obegränsade privata repositories för team upp till 3 personer. GitHub är populärt i open-source-communityn.

GitLab är en komplett DevOps-plattform med integrerad CI/CD, containerregister och infrastrukturhantering. Till skillnad från GitHub kan GitLab installeras på din egen server (Self-Managed). Bitbucket från Atlassian är tätt integrerat med Jira och Confluence, vilket gör det till valet för team som redan använder Atlassian-ekosystemet.