Git Flow: vad är det, förgreningsmodell och användning i projekt

Vad är Git Flow?

Git Flow — är en Git-förgreningsmodell som fastställer en strikt struktur av grenar och sammanslagningsregler för att hantera utveckling, releases och korrigeringar. Vincent Driessen publicerade artikeln „A successful Git branching model“ i januari 2010 och sedan dess har Git Flow blivit de facto-standard inom företags Java- och .NET-utveckling. Huvudidén — att dela upp koden i fem gren typer med olika stabilitetsnivåer.

Enligt Atlassian Git Tutorials, 2024, är Git Flow baserat på två permanenta grenar: main (tidigare master) och develop. Alla andra grenar är tillfälliga: feature, release, hotfix. Varje gren typ har en tydligt definierad livscykel och sammanslagningsregler. Inom mobilutveckling tillämpas Git Flow i projekt med regelbundna releasecykler (2–4 veckor) och stöd för flera versioner.

Git Flow skiljer sig från enkla modeller (GitHub Flow) genom att det kräver en separat develop-gren för integration. Detta lägger till ett steg i sammanslagningsprocessen, men ger ytterligare isolering av oavslutade funktioner från releasesklar kod.

Vincent Driessen och historien om Git Flow

2010 publicerade Vincent Driessen inlägget „A successful Git branching model“, som blev ett av de mest citerade i Git-historien. Modellen skapades för ett projekt med fasta releases och parallellt versionsstöd. 2020 erkände Driessen att Git Flow är föråldrat för moderna CI/CD-praxis, men modellen förblir relevant för projekt med lång releasecykel och behov av att stödja gamla versioner.

# Initiera Git Flow
git flow init

# Skapa feature-gren
git flow feature start "add-auth"

# Slutföra feature-gren (sammanslagning i develop)
git flow feature finish "add-auth"

# Skapa release
git flow release start "1.2.0"
git flow release finish "1.2.0"

Main-gren: releaseskod och taggning

Main (tidigare master) — huvudgrenen som endast innehåller releaseskod redo för driftsättning. Varje commit i main måste motsvara en specifik produktversion, märkt med en tagg i formatet för semantisk versionshantering, till exempel v1.0.0, v1.1.0. Ingen direkt utveckling i main utförs — ändringar kommer hit endast via release- eller hotfix-grenar.

Enligt semver.org, 2024, använder taggar i main formatet MAJOR.MINOR.PATCH. MAJOR ökas vid inkompatibla API-ändringar, MINOR — vid tillägg av funktionalitet med bakåtkompatibilitet, PATCH — vid korrigering av buggar. I Git Flow skapar varje finish release automatiskt en commit i main med en versionstagg.

Main — den enda grenen som driftsätts i produktion. För mobilprojekt innebär detta att vid push till main startas pipeline för att bygga App Bundle eller IPA och publicera till Google Play / App Store. I GitLab CI/CD-inställningar är main skyddad mot force-push och borttagning.

Semantisk versionshantering och taggar

Varje commit i main åtföljs av en tagg i SemVer-format: vMAJOR.MINOR.PATCH. MAJOR — för inkompatibla API-ändringar, MINOR — för ny funktionalitet med bakåtkompatibilitet, PATCH — för korrigering av buggar. Exempel: v2.1.0 betyder den andra stora releasen med nya funktioner och utan buggfixar. I Git Flow skapas taggar automatiskt vid finish release eller hotfix via kommandot git flow release finish.

Develop-gren: integrationslinje för utveckling

Develop — den andra permanenta Git Flow-grenen, avsedd för integration av alla slutförda funktioner. Utvecklare slår samman feature-grenar i develop efter att ha passerat kodgranskning och CI/CD-kontroller. Develop innehåller den senaste stabila kodversionen som inkluderar alla implementerade funktioner från den aktuella sprinten.

Enligt DataSift Git Flow Guide, 2024, kan develop vara tillfälligt instabil på grund av oavslutade integrationer. För att förebygga problem tillämpar team Continuous Integration (CI): varje funktion genomgår en komplett testsvit innan sammanslagning i develop. Om CI misslyckas — korrigerar utvecklaren koden till nästa sammanslagning. Develop är alltid kopplad till den aktuella versionen av main: omedelbart efter en release synkroniseras develop med main genom sammanslagning.

Feature-grenar: utveckling av ny funktionalitet

Feature-grenar — tillfälliga grenar för att utveckla enskilda funktioner, buggfixar eller experiment. Varje feature-gren skapas från develop och efter slutförande slås den tillbaka till develop. Feature-grenens namn innehåller vanligtvis uppgiftsnumret eller en kort beskrivning: feature/APP-123-add-oauth, feature/redesign-profile. I Git Flow kan feature-grenar existera under obegränsad tid.

Enligt Pro Git Book, 2024, är feature-grenar en isolerad utvecklingsmiljö: ändringar i en gren påverkar inte andra förrän vid sammanslagning. I mobilprojekt synkroniseras feature-grenar med develop via rebase eller merge för att undvika stora konflikter vid slutförande. Det rekommenderas att rebasa feature-grenen på develop innan du skapar en MR.

# Manuell skapande av feature-gren (utan git flow)
git checkout -b feature/APP-142-add-auth develop
git commit -m "Add OAuth2 authentication with Google"
git push origin feature/APP-142-add-auth

# Skapa MR i GitLab via CLI
glab mr create \
    --source-branch "feature/APP-142-add-auth" \
    --target-branch "develop" \
    --title "Add OAuth2 authentication"

Release-grenar: förbereda release

Release-grenar — tillfälliga grenar skapade från develop för att förbereda en release. När develop innehåller en tillräcklig uppsättning funktioner för en ny version, skapar teamet en release/X.Y.Z-gren (till exempel release/2.1.0). I denna gren görs endast slutliga ändringar: versionsökning, lokaliseringsuppdatering, slutlig testning, korrigering av kritiska buggar.

Enligt Atlassian Git Tutorials, 2024, löser release-grenen ett nyckelproblem: isolering av slutliga ändringar från parallell utveckling. Medan release förbereds för lansering, fortsätter nya funktioner att slås samman i develop för nästa release. Efter slutförande slås release-grenen samman i main (med tagg) och i develop (för att synkronisera versionsökningen).

Hotfix-grenar: akuta korrigeringar i produktion

Hotfix-grenar — tillfälliga grenar för akut korrigering av kritiska buggar i produktion. Den enda Git Flow-gren typen som skapas från main, inte från develop. Namnformat: hotfix/X.Y.Z+1 (till exempel hotfix/2.1.1). Efter slutförande slås hotfix-grenen samtidigt samman i main (som en ny patch-release) och i develop (så att korrigeringen inte går förlorad vid nästa releaser).

Enligt DataSift Git Flow Guide, 2024, bör hotfix-grenar vara så korta som möjligt — endast korrigering och test. Hotfix bör inte inkludera nya funktioner eller refaktorisering. Inom mobilutveckling används hotfix för att korrigera kritiska krascher (crash rate > 0.1%), säkerhetsbrister eller blockerande buggar i App Store.

För- och nackdelar med Git Flow för mobilutveckling

Git Flow ger en tydlig struktur som är särskilt användbar för stora team och projekt med regelbundna releases. Fördelar: isolering av oavslutade funktioner i feature-grenar, möjlighet att förbereda release utan att blockera utveckling, stöd för flera versioner via hotfix. Nackdelar: komplexitet för nybörjare, behov av regelbunden rebase av feature-grenar, konflikter vid långlivade grenar.

Enligt Martin Fowler, 2024, är den största nackdelen med Git Flow — långlivade feature-grenar. Om en funktion utvecklas i 2+ veckor utan synkronisering med develop, blir konflikten vid sammanslagning betydande. För mobilprojekt rekommenderas daglig synkronisering av feature-grenen via rebase på develop.

Git Flow rekommenderas inte för projekt med Continuous Deployment (varje commit i main → till produktion). För sådana projekt ger GitHub Flow eller Trunk-Based Development en enklare och snabbare modell. Men för projekt med releasecykler och stöd för gamla versioner förblir Git Flow det optimala valet.

När Git Flow är skadligt för teamet

Git Flow blir ett problem i tre fall: team mindre än 5 personer (överdriven komplexitet), Continuous Deployment (leveransförsening), brist på rebase-disciplin (långlivade feature-grenar skapar sammanslagningskonflikter). Om teamet lägger mer än 20% av tiden på att slå samman grenar och lösa konflikter — är Git Flow inte lämpligt för detta team, även vid stor storlek.

Alternativ till Git Flow: GitHub Flow och Trunk-Based Development

Alternativ till Git Flow erbjuder en enklare process för team som tillämpar CI/CD. GitHub Flow använder endast en permanent gren (main) och feature-grenar. Varje funktion skapas från main, efter granskning och CI slås den tillbaka till main och driftsätts omedelbart. GitHub Flow är enklare, men stöder inte isolering av oavslutade funktioner och parallell releaseförberedelse.

Enligt GitHub Docs, 2024, går Trunk-Based Development (TBD) ännu längre: alla utvecklare arbetar i en gren (trunk) och använder kortlivade feature-grenar på 1–2 dagar. Feature toggles (funktionsväxlar) styr synligheten av oavslutad kod. TBD kräver hög CI/CD-disciplin och testautomatisering.

• GitHub Flow — en main + feature-grenar, idealisk för CI/CD och små team
• GitLab Flow — utvecklar Git Flow med miljö-grenar (staging, production)
• Trunk-Based Development — en gren + feature toggles, maximal CI/CD, minimal sammanslagning
• One Flow — förenklad Git Flow utan develop-gren, endast main + feature + release