Git-tutorial: Gitflow of trunk-based, welk branchmodel kies je

Git legt je geen enkele organisatie op. Het geeft je de branches uit het vorige hoofdstuk, en jij bepaalt welke er bestaan, wie ze aanmaakt en wanneer ze samenkomen. Die keuze heet een branchmodel, en twee grote families verdelen het terrein: Gitflow en trunk-based development. Dit hoofdstuk behandelt ze allebei, met de echte commando’s, en legt uit in welke context elk model op zijn plaats is.

Wat er van Gitflow geworden is

Gitflow werd in januari 2010 beschreven door Vincent Driessen, in een artikel met de titel A successful Git branching model. Het model is massaal overgenomen, tot het voor een hele generatie developers de standaardreflex werd.

Op 5 maart 2020 zette de auteur bovenaan zijn eigen artikel een kanttekening. Die is het lezen waard voordat je het model overneemt: voor een team dat continu levert, raadt hij expliciet een veel eenvoudigere werkwijze aan, in de trant van GitHub Flow, in plaats van Gitflow er met de schoenlepel in te duwen. Hij tekent daarbij aan dat Gitflow zijn nut behoudt voor software die expliciet in versies verschijnt, of waarvan meerdere versies tegelijk in productie onderhouden moeten worden.

De vraag is met andere woorden niet “is Gitflow goed of slecht”, maar “wat lever ik op, en in welk tempo”.

Trunk-based development

Het principe past in één zin: één langlevende branch, main, waarop iedereen zijn werk heel vaak integreert, via branches met een zeer korte levensduur.

Een branch leeft een paar uur, een dag, zelden langer. Hij gaat terug zodra het werk samenhangend is, ook al is de functionaliteit nog niet af: wat gebruikers nog niet mogen zien, verberg je achter een feature flag in plaats van het op een branch vast te houden. main is permanent deploybaar, en het is continuous integration die dat garandeert.

# 1. vertrek vanaf de laatste versie van main
git switch main
git pull --rebase

# 2. een korte branch, voor één ding
git switch -c fix/calcul-prix

# 3. werken, committen
git commit -am "Corrige le calcul du prix TTC"

# 4. pushen en een pull request openen
git push -u origin fix/calcul-prix

# 5. na review en groen licht van de CI, mergen in main
git switch main
git merge --no-ff -m "Fusionne fix/calcul-prix" fix/calcul-prix
git branch -d fix/calcul-prix

Merge made by the 'ort' strategy.
 app.js | 1 +
 1 file changed, 1 insertion(+)
Deleted branch fix/calcul-prix (was 711bcbc).

*   d7cdba6 Fusionne fix/calcul-prix
|  
| * 711bcbc Corrige le calcul du prix TTC
|/  
* 5b45117 Ajoute app.js
* 38b7dc5 Ajoute la doc

De optie --no-ff dwingt een merge-commit af, zelfs wanneer een simpele fast-forward had volstaan. De geschiedenis toont zo expliciet dat een branch heeft bestaan en wat hij bevatte. Zonder -m opent Git de in hoofdstuk 1 geconfigureerde editor met een vooraf ingevulde boodschap. In de praktijk doen de knoppen Merge pull request van GitHub en Merge request van GitLab dit werk voor jou.

Versies markeer je met tags op main, zonder aparte branch:

git tag -a v1.0.0 -m "Première version publique"
git push origin v1.0.0

tag v1.0.0
Tagger: Damien Flandrin <dam@example.com>
Date:   Wed Sep 2 10:00:00 2026 +0000

Première version publique

Kies altijd de geannoteerde tag (-a met een bericht) boven de lichte tag: die legt de auteur, de datum en een toelichting vast. En vergeet het bericht niet: zonder -m opent Git een editor, en in een geautomatiseerde omgeving mislukt het commando.

error: there was a problem with the editor 'false'
Please supply the message using either -m or -F option.

Gitflow

Gitflow voegt een tweede permanente branch toe, plus drie families tijdelijke branches.

Let op: in het artikel uit 2010 heette de productiebranch nog master. Omdat hosters vandaag repository’s aanmaken op main, wordt hier die naam gebruikt.

Gitflow met de hand

Je hebt er geen enkele tool voor nodig, het model is niet meer dan branchdiscipline.

# de integratiebranch aanmaken, eens en voor altijd
git switch -c develop
git push -u origin develop

# een functionaliteit
git switch -c feature/livraison develop
git commit -am "Ajoute le calcul des frais de livraison"
git switch develop
git merge --no-ff -m "Fusionne feature/livraison" feature/livraison
git branch -d feature/livraison

# een versie
git switch main
git merge --no-ff -m "Version 1.2.0" develop
git tag -a v1.2.0 -m "Version 1.2.0"

*   876ffba Version 1.2.0
|  
| * 269874d Fusionne feature/livraison
|/| 
| * afcc714 Ajoute la livraison
|/  
*   d7cdba6 Fusionne correctif/prix
|  
| * 711bcbc Corrige le calcul du prix
|/  
* 5b45117 Ajoute app.js

Gitflow met de tool git-flow

Er bestaat een set commando’s die deze reeksen automatiseert. Het oorspronkelijke project wordt niet meer onderhouden, de AVH-editie wel, en die zit in de meeste pakketbeheerders onder de naam git-flow.

git flow init -d       # -d accepteert alle standaardnamen

Using default branch names.

Which branch should be used for bringing forth production releases?
   - main
Branch name for production releases: [main] 
Branch name for "next release" development: [develop] 

How to name your supporting branch prefixes?
Feature branches? [feature/] 
Bugfix branches? [bugfix/] 
Release branches? [release/] 
Hotfix branches? [hotfix/] 
Support branches? [support/] 
Version tag prefix? [] 
Hooks and filters directory? [/root/a8/.git/hooks] 

De cyclus van een functionaliteit past daarna in twee commando’s:

git flow feature start facturation
# … je werkt en commit …
git flow feature finish facturation

Switched to branch 'develop'
Updating 5b45117..61c7618
Fast-forward
 facture.php | 1 +
 1 file changed, 1 insertion(+)
Deleted branch feature/facturation (was 61c7618).

Summary of actions:
- The feature branch 'feature/facturation' was merged into 'develop'
- Feature branch 'feature/facturation' has been locally deleted
- You are now on branch 'develop'

En die van een versie eveneens in twee. git flow release finish merget in main, zet de tag en brengt het geheel daarna terug in develop:

git flow release start 1.1.0
# … versienummer bijwerken, laatste fixes …
git flow release finish -m "Version 1.1.0" 1.1.0

*   1b1a31d Merge tag '1.1.0' into develop
|  
| *   48f5649 Merge branch 'release/1.1.0'
| |  
| | * eb133dd Prepare la version 1.1.0
| |/  
|/|   
* | 61c7618 Ajoute la facturation
|/  
* 5b45117 Ajoute app.js

Deze graaf illustreert precies het verwijt dat het model krijgt: drie merge commits voor een versie die maar één functionaliteit bevatte.

Welk model kies je

Kies trunk-based development als je een webapplicatie of een dienst levert die je vaak deployt, als er telkens maar één versie in productie staat, als je team klein is en als je geautomatiseerde tests hebt die die naam waard zijn. Dat geldt voor de grote meerderheid van de webprojecten van vandaag, en dat is het model dat je standaard aanhoudt.

Kies Gitflow als je genummerde versies publiceert die je gebruikers zelf installeren, als je meerdere versies parallel moet onderhouden, als een formele acceptatiefase het einde van de ontwikkeling scheidt van de ingebruikname, of als je onder regelgeving werkt die traceerbaarheid per versie oplegt. Libraries, desktopapplicaties, embedded software, on-premise versies bij klanten: daar behoudt het model al zijn relevantie.

Begin je in je eentje, dan geen van beide. Werk op main, maak een branch wanneer je iets onzekers uitprobeert en zet een tag zodra je tevreden bent. Een model neem je aan op de dag dat je met meerderen bent, en die dag is trunk-based het eenvoudigst op te zetten.

Nog een laatste advies: neem geen model over omdat het als serieus te boek staat. Een Gitflow toegepast door een team van twee dat elke dag deployt, levert lege release-branches en nutteloze merges op. Het goede model is het model dat past bij de manier waarop je levert.

Hoe verder

Je hebt nu de basis van Git te pakken. Drie richtingen zijn daarna de moeite waard.

Eerst continuous integration, de onmisbare aanvulling op trunk-based development: je tests automatisch laten draaien bij elke push. GitHub Actions en GitLab CI zitten in die platformen ingebouwd en configureer je met een simpel YAML-bestand in je repository.

Daarna de mergeverzoeken, pull requests op GitHub, merge requests op GitLab. Zij organiseren de code review in een team, en in beide modellen hier zijn zij de echte toegangspoort tot main.

Tot slot de noodcommando’s: git bisect om via binair zoeken de commit te vinden die een bug heeft geïntroduceerd, git cherry-pick om een specifieke commit uit een andere branch op te halen, en git worktree om meerdere branches tegelijk in meerdere mappen te openen.

De volledige inhoudsopgave blijft bereikbaar via de tutorial Git leren, en de overige tutorials uit het traject vind je in de hub Webdevelopment.