Git workflow för team: Branching-strategier som fungerar

Git är enkelt att lära sig och svårt att behärska — särskilt i team. En branching-strategi som fungerar för två utvecklare kan bli en mardröm för tjugo. Och en strategi som passar en startup med snabba releases funkar inte för ett team som kör kvartalsvisa deploys.

Den här guiden jämför de tre vanligaste branching-strategierna med ärliga bedömningar av när de fungerar och när de inte gör det.

Trunk-Based Development

Alla commitar direkt till main (eller via kortlivade feature-branches som lever max 1-2 dagar). Det finns ingen develop-branch, inga release-branches, och merge-konflikter är sällsynta eftersom alla jobbar med samma kodbas.

# Trunk-Based Development workflow
# 1. Hämta senaste main
git checkout main
git pull origin main

# 2. Skapa kortlivad branch (max 1-2 dagar)
git checkout -b feat/add-search

# 3. Gör små, inkrementella commits
git add src/components/Search.tsx
git commit -m "Add search component skeleton"

git add src/hooks/useSearch.ts
git commit -m "Add search hook with debounce"

# 4. Pusha och skapa PR
git push origin feat/add-search
gh pr create --title "Add search functionality"

# 5. Code review → squash merge → branch borttagen
# Hela processen: 4 timmar till 2 dagar

Fungerar när: Teamet har bra testning (CI blockerar trasig kod), feature flags för att dölja halvfärdig funktionalitet, och en kultur av små, frekventa merges. Google och Meta använder trunk-based development.

Fungerar inte när: Du inte har CI/CD, teamet gör stora features som tar veckor, eller du behöver stödja flera produktionsversioner parallellt.

GitHub Flow

En förenklad strategi: main är alltid redo för deploy. All utveckling sker i feature-branches som mergeas via pull requests. Det finns bara en permanent branch.

# GitHub Flow
# 1. Skapa branch från main
git checkout main && git pull
git checkout -b feature/user-profiles

# 2. Jobba i din branch
git add .
git commit -m "Add user profile page"
git commit -m "Add avatar upload"
git commit -m "Add profile settings form"

# 3. Pusha och öppna PR
git push origin feature/user-profiles
gh pr create --title "User profiles"

# 4. Code review med diskussion
# Teammedlemmar granskar, kommenterar, godkänner

# 5. Merge till main → automatisk deploy
# main är ALLTID i deploybart tillstånd

# Tips: Squash merge för ren historik
git merge --squash feature/user-profiles
git commit -m "Add user profiles (#42)"
# Alla individuella commits blir en enda commit

Fungerar när: Du deployer ofta (dagligen eller oftare), har ett team på 2-15 utvecklare, och dina features kan levereras inkrementellt.

Fungerar inte när: Du behöver hantera flera parallella releaser (version 3.1 och 3.2 samtidigt) eller har långa QA-cykler.

Git Flow

Den mest strukturerade strategin: main speglar produktion,develop är integrationsgrenen, feature-branches skapas från develop, och release-branches förbereder deployments.

# Git Flow — fullständig cykel
# Permanenta branches: main, develop
# Temporära: feature/*, release/*, hotfix/*

# 1. Feature-utveckling
git checkout develop
git checkout -b feature/payment-system
# ... arbeta i dagar/veckor ...
git checkout develop
git merge --no-ff feature/payment-system

# 2. Release-förberedelse
git checkout develop
git checkout -b release/2.0.0
# Buggfixar och förberedelser i release-branch
git commit -m "Bump version to 2.0.0"
git commit -m "Fix edge case in payment flow"

# 3. Release → merge till BÅDE main och develop
git checkout main
git merge --no-ff release/2.0.0
git tag -a v2.0.0 -m "Release 2.0.0"

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

# 4. Hotfix (kritisk bugg i produktion)
git checkout main
git checkout -b hotfix/payment-crash
git commit -m "Fix null pointer in payment handler"
git checkout main
git merge --no-ff hotfix/payment-crash
git tag -a v2.0.1

# Merge hotfix tillbaka till develop också
git checkout develop
git merge --no-ff hotfix/payment-crash

Fungerar när: Du har schemalagda releaser (varannan vecka, månatligen), behöver stödja hotfixes på produktionversionen, eller har ett större team (15+) med separata QA-faser.

Fungerar inte när: Du vill deploya flera gånger per dag, teamet är litet (2-5 personer), eller den extra komplexiteten inte motiveras av era release-behov.

Commit-meddelanden som hjälper teamet

Oavsett branching-strategi: bra commit-meddelanden gör skillnad. Conventional Commits ger en standard som fungerar för changelogs, semantic versioning och sökbarhet.

# Conventional Commits
feat: add user search with autocomplete
fix: prevent duplicate form submissions
refactor: extract validation to shared module
docs: add API authentication guide
test: add unit tests for payment calculator
chore: update dependencies

# Med scope (optional)
feat(auth): add OAuth 2.0 login flow
fix(api): handle timeout in product endpoint

# Breaking change
feat!: change API response format to JSON:API

# Med body och footer
feat: add dark mode support

Implements automatic theme switching based on
system preferences. Falls back to light mode
if prefers-color-scheme is not supported.

Closes #234

Vilken strategi ska du välja?

Börja enkelt. GitHub Flow fungerar för de flesta team. Byt till trunk-based om ni vill gå snabbare, eller Git Flow om ni behöver mer struktur.

Det viktigaste är inte vilken strategi ni väljer — det är att hela teamet följer den konsekvent. En halvhjärtat implementerad strategi är värre än ingen alls.

Läs mer om moderna utvecklingsverktyg i vår webbutvecklingsguide för 2026.