Git Flow: wat is het, vertakkingsmodel en gebruik in projecten

Wat is Git Flow?

Git Flow — is een Git-vertakkingsmodel dat een strikte structuur van takken en samenvoegingsregels vastlegt voor het beheren van ontwikkeling, releases en fixes. Vincent Driessen publiceerde het artikel 'A successful Git branching model' in januari 2010 en sindsdien is Git Flow de de facto standaard geworden in bedrijfs-Java- en .NET-ontwikkeling. Het hoofdidee — het verdelen van code in vijf taktypes met verschillende niveaus van stabiliteit.

Volgens Atlassian Git Tutorials, 2024, is Git Flow gebaseerd op twee permanente takken: main (voorheen master) en develop. Alle andere takken zijn tijdelijk: feature, release, hotfix. Elk taktype heeft een duidelijk gedefinieerde levenscyclus en samenvoegingsregels. In mobiele ontwikkeling wordt Git Flow toegepast in projecten met regelmatige releasecycli (2–4 weken) en ondersteuning voor meerdere versies.

Git Flow verschilt van eenvoudige modellen (GitHub Flow) doordat het een aparte develop-tak vereist voor integratie. Dit voegt een stap toe aan het samenvoegingsproces, maar zorgt voor extra isolatie van onvoltooide functies van code die klaar is voor release.

Vincent Driessen en de geschiedenis van Git Flow

In 2010 publiceerde Vincent Driessen het bericht 'A successful Git branching model', dat een van de meest geciteerde in de geschiedenis van Git werd. Het model werd gemaakt voor een project met vaste releases en parallelle versieondersteuning. In 2020 gaf Driessen toe dat Git Flow verouderd is voor moderne CI/CD-praktijken, maar het model blijft relevant voor projecten met een lange releasecyclus en de noodzaak om oude versies te ondersteunen.

# Git Flow initialiseren
git flow init

# Feature-tak aanmaken
git flow feature start "add-auth"

# Feature-tak voltooien (samenvoegen in develop)
git flow feature finish "add-auth"

# Release aanmaken
git flow release start "1.2.0"
git flow release finish "1.2.0"

Main-tak: releasecode en taggen

Main (voorheen master) — de hoofdtak die alleen releasecode bevat die klaar is voor implementatie. Elke commit in main moet overeenkomen met een specifieke productversie, gemarkeerd met een tag in het formaat van semantische versiebeheer, bijvoorbeeld v1.0.0, v1.1.0. Er wordt geen directe ontwikkeling in main uitgevoerd — wijzigingen komen hier alleen via release- of hotfix-takken.

Volgens semver.org, 2024, gebruiken tags in main het MAJOR.MINOR.PATCH-formaat. MAJOR wordt verhoogd bij incompatibele API-wijzigingen, MINOR — bij toevoeging van functionaliteit met achterwaartse compatibiliteit, PATCH — bij het oplossen van bugs. In Git Flow maakt elke finish release automatisch een commit in main met een versietag.

Main — de enige tak die in productie wordt geïmplementeerd. Voor mobiele projecten betekent dit dat bij push naar main de pipeline voor het bouwen van App Bundle of IPA en publicatie naar Google Play / App Store wordt gestart. In GitLab CI/CD-instellingen is main beschermd tegen force-push en verwijdering.

Semantische versiebeheer en tags

Elke commit in main gaat vergezeld van een tag in SemVer-formaat: vMAJOR.MINOR.PATCH. MAJOR — voor incompatibele API-wijzigingen, MINOR — voor nieuwe functionaliteit met achterwaartse compatibiliteit, PATCH — voor het oplossen van bugs. Voorbeeld: v2.1.0 betekent de tweede grote release met nieuwe functies en zonder bugfixes. In Git Flow worden tags automatisch aangemaakt bij finish release of hotfix via het commando git flow release finish.

Develop-tak: integratielijn van ontwikkeling

Develop — de tweede permanente Git Flow-tak, bedoeld voor de integratie van alle voltooide functies. Ontwikkelaars voegen feature-takken samen in develop na het doorlopen van code review en CI/CD-checks. Develop bevat de meest recente stabiele codeversie, inclusief alle geïmplementeerde functies van de huidige sprint.

Volgens DataSift Git Flow Guide, 2024, kan develop tijdelijk onstabiel zijn vanwege onvoltooide integraties. Om problemen te voorkomen, passen teams Continuous Integration (CI) toe: elke functie doorloopt een volledige testreeks voordat deze in develop wordt samengevoegd. Als CI faalt — lost de ontwikkelaar de code op tot de volgende samenvoeging. Develop is altijd gekoppeld aan de huidige versie van main: direct na een release wordt develop gesynchroniseerd met main via samenvoeging.

Feature-takken: ontwikkeling van nieuwe functionaliteit

Feature-takken — tijdelijke takken voor het ontwikkelen van individuele functies, bugfixes of experimenten. Elke feature-tak wordt gemaakt van develop en na voltooiing terug samengevoegd in develop. De naam van een feature-tak bevat meestal het taaknummer of een korte beschrijving: feature/APP-123-add-oauth, feature/redesign-profile. In Git Flow kunnen feature-takken onbeperkt lang bestaan.

Volgens Pro Git Book, 2024, zijn feature-takken een geïsoleerde ontwikkelomgeving: wijzigingen in de ene tak beïnvloeden andere niet tot het moment van samenvoeging. In mobiele projecten worden feature-takken gesynchroniseerd met develop via rebase of merge om grote conflicten bij finish te voorkomen. Het wordt aanbevolen om de feature-tak te rebasen op develop voordat een MR wordt gemaakt.

# Feature-tak handmatig aanmaken (zonder 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

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

Release-takken: release voorbereiden

Release-takken — tijdelijke takken gemaakt van develop om een release voor te bereiden. Wanneer develop voldoende functies bevat voor een nieuwe versie, maakt het team een release/X.Y.Z-tak (bijvoorbeeld release/2.1.0). In deze tak worden alleen laatste wijzigingen aangebracht: versieverhoging, lokalisatie-update, laatste tests, oplossen van kritieke bugs.

Volgens Atlassian Git Tutorials, 2024, lost de release-tak een kernprobleem op: isolatie van laatste wijzigingen van parallelle ontwikkeling. Terwijl de release wordt voorbereid, worden in develop nog nieuwe functies voor de volgende release samengevoegd. Na voltooiing wordt de release-tak samengevoegd in main (met tag) en in develop (om de versieverhoging te synchroniseren).

Hotfix-takken: dringende fixes in productie

Hotfix-takken — tijdelijke takken voor het dringend oplossen van kritieke bugs in productie. Het enige Git Flow-taktype dat wordt gemaakt van main, niet van develop. Naamformaat: hotfix/X.Y.Z+1 (bijvoorbeeld hotfix/2.1.1). Na voltooiing wordt de hotfix-tak gelijktijdig samengevoegd in main (als een nieuwe patchrelease) en in develop (zodat de fix niet verloren gaat bij volgende releases).

Volgens DataSift Git Flow Guide, 2024, moeten hotfix-takken zo kort mogelijk zijn — alleen fix en test. Hotfix mag geen nieuwe functies of refactoring bevatten. In mobiele ontwikkeling wordt hotfix toegepast voor het oplossen van kritieke crashes (crash rate > 0.1%), beveiligingslekken of blokkerende bugs in de App Store.

Voor- en nadelen van Git Flow voor mobiele ontwikkeling

Git Flow biedt een duidelijke structuur die vooral nuttig is voor grote teams en projecten met regelmatige releases. Voordelen: isolatie van onvoltooide functies in feature-takken, mogelijkheid om een release voor te bereiden zonder ontwikkeling te blokkeren, ondersteuning voor meerdere versies via hotfix. Nadelen: complexiteit voor beginners, noodzaak voor regelmatige rebase van feature-takken, conflicten bij langlevende takken.

Volgens Martin Fowler, 2024, is het grootste nadeel van Git Flow — langlevende feature-takken. Als een functie 2+ weken wordt ontwikkeld zonder synchronisatie met develop, wordt het conflict bij samenvoeging aanzienlijk. Voor mobiele projecten wordt aanbevolen om de feature-tak dagelijks te synchroniseren via rebase op develop.

Git Flow wordt niet aanbevolen voor projecten met Continuous Deployment (elke commit in main → naar productie). Voor dergelijke projecten bieden GitHub Flow of Trunk-Based Development een eenvoudiger en sneller model. Maar voor projecten met releasecycli en ondersteuning voor oude versies blijft Git Flow de optimale keuze.

Wanneer Git Flow schadelijk is voor het team

Git Flow wordt een probleem in drie gevallen: team kleiner dan 5 personen (overmatige complexiteit), Continuous Deployment (leveringsvertraging), gebrek aan rebase-discipline (langlevende feature-takken creëren samenvoegconflicten). Als een team meer dan 20% van de tijd besteedt aan het samenvoegen van takken en het oplossen van conflicten — is Git Flow niet geschikt voor dit team, zelfs niet bij grote omvang.

Alternatieven voor Git Flow: GitHub Flow en Trunk-Based Development

Alternatieven voor Git Flow bieden een eenvoudiger proces voor teams die CI/CD toepassen. GitHub Flow gebruikt slechts één permanente tak (main) en feature-takken. Elke functie wordt gemaakt van main, na review en CI terug samengevoegd in main en onmiddellijk geïmplementeerd. GitHub Flow is eenvoudiger, maar ondersteunt geen isolatie van onvoltooide functies en parallelle releasevoorbereiding.

Volgens GitHub Docs, 2024, gaat Trunk-Based Development (TBD) nog verder: alle ontwikkelaars werken in één tak (trunk) met kortlevende feature-takken van 1–2 dagen. Feature toggles (functieschakelaars) beheren de zichtbaarheid van onvoltooide code. TBD vereist hoge CI/CD-discipline en testautomatisering.

• GitHub Flow — één main + feature-takken, ideaal voor CI/CD en kleine teams
• GitLab Flow — ontwikkelt Git Flow met omgevingstakken (staging, production)
• Trunk-Based Development — één tak + feature toggles, maximale CI/CD, minimale samenvoegingen
• One Flow — vereenvoudigd Git Flow zonder develop-tak, alleen main + feature + release