GitFlow-tutorial: branching voor features, releases en hotfixes

GitFlow instellen

Voordat je profiteert van het gestructureerde branchingmodel van GitFlow, moet je het op je machine installeren en in je repository initialiseren. Gelukkig zijn beide stappen eenvoudig.

Om GitFlow te gebruiken, moet Git al op je machine geïnstalleerd zijn. Je kunt meer lezen over het installeren van Git in de Git Install Tutorial.

GitFlow installeren

GitFlow is een extensie van Git, dus je moet het apart installeren. Standaard wordt het niet met Git meegeleverd. Het installatieproces hangt af van je besturingssysteem.

Voor meer gedetailleerde instructies over het installeren van GitFlow, lees de officiële documentatie.

Let op: hoewel de GitFlow-extensie hierboven het beheer van feature-branches, releases en hotfixes met eenvoudige commando’s makkelijker maakt, is het niet strikt vereist. Je kunt de GitFlow-workflow volgen met standaard Git-commando’s—zolang je consistent bent met naamgeving en merge-praktijken. De tool automatiseert en handhaaft het proces, wat handig kan zijn voor teams of grotere projecten.

macOS

Gebruik je Homebrew, de populairste package manager voor macOS, voer dan uit:

brew install git-flow-avh

Linux (Debian/Ubuntu-gebaseerd)

Als je op een Debian-gebaseerd systeem zoals Ubuntu zit, gebruik dan:

sudo apt-get install git-flow

Windows

Op Windows kun je GitFlow installeren via Git for Windows en Git Bash aan je terminal toevoegen.

Om te checken of GitFlow is geïnstalleerd, kun je uitvoeren:

git flow version

GitFlow initialiseren in een repository

Als eerste stap heb je een geïnitialiseerde Git-repository nodig voordat je GitFlow gebruikt. Je kunt meer lezen in How to Initialize and Set Up a Git Repository.

Zodra GitFlow is geïnstalleerd, kun je het in elke bestaande Git-repository initialiseren met:

git flow init

GitFlow vraagt je vervolgens om een aantal instellingen te configureren. Hier is een overzicht van wat ze betekenen en hoe je de juiste kiest:

1. Branchnamen: je wordt gevraagd naar de standaard branchnamen.
1. Naam van productiebranch (standaard: master)
2. Naam van ontwikkelbranch (standaard develop)
2. Voorvoegsels voor ondersteunende branches: GitFlow gebruikt naamgevingsconventies voor de verschillende soorten branches.
1. Feature-branches: feature/
2. Bugfix-branches: bugfix/
3. Release-branches: release/
4. Hotfix-branches: hotfix/
5. Support-branches: support/ (zelden gebruikt in de praktijk)
6. Versietag-voorvoegsel: v (bijv. v.1.2.0)

De standaardinstellingen werken voor de meeste teams prima, maar je kunt ze aanpassen aan de naamgevingsstandaarden van je organisatie.

Voorbeeldoutput van initialisatie:

git flow init

Which branch should be used for bringing forth production releases?
   - master
Branch name for production releases: [master]
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? [] v

Na het initialiseren kun je de develop-branch naar je remote repository pushen. Lees meer over pushen en pullen van branches in de Git Push and Pull Tutorial.

GitFlow gebruiken voor ontwikkeling

Zodra GitFlow in je repository is geïnstalleerd, kun je het branchingmodel gebruiken om je ontwikkelworkflow te beheren. GitFlow biedt high-level commando’s voor het werken met features, releases en hotfixes, waardoor structuur behouden blijft en Git-chaos wordt voorkomen.

In de volgende subhoofdstukken bekijken we GitFlow in de praktijk.

Feature-branches aanmaken

Feature-branches worden gebruikt om nieuwe functionaliteit te ontwikkelen zonder de hoofdcodebase te beïnvloeden.

Je maakt een feature-branch aan met:

git flow feature start <feature-name>

Deze opdracht maakt een nieuwe branch van develop met de naam feature/<feature-name>. Je kunt je feature ontwikkelen en zoals gebruikelijk commits maken.

Feature-branches afronden

Als je feature af is en getest, kun je ’m afronden met: 

git flow feature finish <feature-name>

Dit doet het volgende:

• Merget je feature-branch in de develop-branch.
• Verwijdert de lokale feature/<feature-name>-branch.

Als je merge-conflicten tegenkomt, los die dan handmatig op en rond de merge af met de standaard conflictoplossingsflow van Git.

Werk je in grotere teams waar eerst pull requests moeten worden aangemaakt en gereviewd, dan kun je niet direct het GitFlow-finish-commando gebruiken, maar kun je het volgende doen:

1. Commit je werk en push vervolgens de branch:

git push origin feature/<feature-name>

2. Maak een pull request van feature/<feature-name> naar develop op GitHub, GitLab, enz.
3. Vraag om review, draai tests en haal goedkeuringen op.
4. Merge na goedkeuring via de UI van het platform en verwijder de branch.

Wil je meer leren over GitHub en hoe je het gebruikt, dan raad ik de cursussen GitHub Foundations en GitHub Concepts aan. In andere teams volg je misschien de standaardflow met git flow feature finish, maar vraag je eerst om een review van je branch voordat je terug merged naar develop en draai je tests op je codewijzigingen om correct gedrag te borgen.

Release-branches aanmaken

Release-branches worden gemaakt om een nieuwe productieversie voor te bereiden zonder de lopende ontwikkeling op de develop-branch te blokkeren.

Om een release te starten, voer je uit:

git flow release start <version-number>

Dit maakt een nieuwe branch genaamd release/<version-number>. Deze branch takte af van develop.

In deze branch rond je meestal versienummers af, fix je kleine bugs en update je documentatie en changelogs.

Release-branches afronden

Als je release klaar is voor productie, rond je ’m af met:

git flow release finish <version-number>

Dit commando:

• Merget de release-branch in zowel master als develop.
• Tagt de release in master (bijv. v1.0.0).
• Verwijdert de lokale release/<release-number>-branch.

Vergeet niet je wijzigingen en tags te pushen:

git push origin master
git push origin develop
git push --tags

# of korter
git push origin master develop --tags

Hotfix-branches aanmaken

Hotfixes worden gebruikt voor urgente productie-fixes wanneer er een bug wordt ontdekt in de master-branch.

Om een hotfix te starten:

git flow hotfix start <version-number>

Dit maakt een hotfix/<version-number>-branch vanaf master. Je kunt nu de wijzigingen toepassen en de fix committen.

Als je klaar bent, rond je af met:

git flow hotfix finish <version-number>

Dit:

• Merget de hotfix in master en develop.
• Tagt de fix op master.
• Verwijdert de lokale `hotfix/<version-number> branch.

Push je lokale wijzigingen en tags zoals gebruikelijk:

git push origin master develop --tags

Hotfixes zijn vooral krachtig omdat je hiermee productieproblemen snel kunt oplossen zonder de lopende ontwikkeling op de develop-branch te verstoren.

Stel je voor dat er al nieuwe features in develop zijn gemerged die je nog niet wilt releasen, maar er een urgent en ernstig probleem in de productieapplicatie moet worden gefixt. 

Dan komen hotfixes goed van pas, omdat ze aftakken van master en daarna alleen worden teruggemerged in develop.

Voorbeeld van GitFlow-branching

Laten we twee veelvoorkomende workflows doorlopen, een feature-ontwikkelcyclus en een release met een hotfix, om GitFlow in actie te zien en te vergelijken met traditionele Git-commando’s.

Door beide kanten te bekijken, snap je beter hoe de GitFlow-extensie het proces vereenvoudigt door meerdere Git-stappen te verpakken in simpele, gestandaardiseerde commando’s.

Heb je een snel overzicht van de traditionele Git-commando’s nodig, bekijk dan de Complete Git Cheat Sheet. Wil je een snelle intro in Git, lees dan GitHub and Git Tutorial for Beginners.

Workflow voor feature-ontwikkeling

Stel dat je een nieuwe feature implementeert die gebruikers laat inloggen op je applicatie. Je noemt deze feature user-authentication.

Met GitFlow:

git flow feature start user-authentication

# Werk aan de feature
git add .
git commit -m "feat: Implement basic user authentication"

# Als je klaar bent:
git flow feature finish user-authentication

git push origin develop

Nu met reguliere Git:

# Maak handmatig een nieuwe branch en switch ernaartoe
git checkout -b feature/user-authentication develop

# Werk aan de feature
git add .
git commit -m "Implement basic user authentication"

# Als je klaar bent
git checkout develop
git merge feature/user-authentication
git branch -d feature/user-authentication
git push origin develop

Zoals je ziet, vermindert GitFlow het aantal commando’s en dus de complexiteit. Het is ook minder foutgevoelig, zoals per ongeluk in de verkeerde branch mergen.

Wil je meer leren over hoe mergen in Git werkt, lees dan Git Merge Tutorial: A Comprehensive Guide with Examples.

Stel nu dat je je voorbereidt op release 1.0.0. Maar kort nadat je de nieuwe versie hebt uitgebracht, wordt er een kritieke bug gevonden die met een hotfix moet worden opgelost. 

Met GitFlow:

# Start een release
git flow release start 1.0.0

# Maak laatste tweaks, update versienummers
git commit -am "Prepare release v1.0.0"

# Rond de release af
git flow release finish 1.0.0
git push origin master develop --tags

Nu heb je de bug gevonden en moet je een hotfix maken:

# Start een hotfix
git flow hotfix start 1.0.1

# Pas de fix toe
git commit -am "Fix login issue in production"

# Rond de hotfix af
git flow hotfix finish 1.0.1
git push origin master develop --tags

En dit alles opnieuw met reguliere Git-commando’s:

# Release handmatig
git checkout -b release/1.0.0 develop

# Breng wijzigingen aan
git commit -am "Prepare release v1.0.0"

# Merge handmatig
git checkout master
git merge release/1.0.0
git tag -a v1.0.0 -m "Release v1.0.0"
git checkout develop
git merge release/1.0.0

# Verwijder release-branch
git branch -d release/1.0.0
git push origin master develop --tags

# Hotfix handmatig
git checkout -b hotfix/1.0.1 master

# Pas fix toe
git commit -am "Fix login issue in production"
git checkout master
git merge hotfix/1.0.1
git tag -a v1.0.1 -m "Hotfix v1.0.1"
git checkout develop
git merge hotfix/1.0.1

# Verwijder hotfix-branch
git branch -d hotfix/1.0.1
git push origin master develop --tags

Best practices voor het gebruik van GitFlow

GitFlow is behoorlijk krachtig en helpt je de code van je team te beheren. Maar om het meeste uit deze structuur te halen, volg je het best een paar best practices.

Deze praktijken helpen branches schoon te houden, merge-conflicten te verminderen en de teamproductiviteit te verbeteren, vooral in samenwerkingsomgevingen.

Consistente branchnamen

Consistentie is key in samenwerking. Houd je aan de standaard naamgevingsconventies van GitFlow, tenzij je team een goede reden heeft om ze aan te passen.

Aanbevolen naamgevingspatronen:

• Feature-branches: feature/<feature-name>
• Release-branches: release/<version-number>
• Hotfix-branches: hotfix/<version-number>

Gebruik ook kebab-case voor namen met meerdere woorden (bijv. feature/user-authentication).

Kleine, frequente wijzigingen

Langdurig levende branches leiden vaak tot pijnlijke merges en enorme pull requests die lastig te reviewen zijn. 

Geloof me, ik heb de merge-conflict-hel al meer dan eens meegemaakt, en dat wil je als het even kan voorkomen!

Houd feature-branches in plaats daarvan kortlevend en focus op één taak. Commit en push regelmatig om geen werk kwijt te raken of te ver af te drijven van develop.

Kleinere, incrementele wijzigingen zijn makkelijker te testen, te reviewen en te integreren.

Regelmatig syncen met develop

Als je aan een feature-branch werkt, moet je niet achterop raken. Zorg dat je regelmatig de laatste wijzigingen van de develop-branch binnenhaalt om latere merge-conflicten te minimaliseren:

git checkout feature/<your-feature>
git fetch origin
git rebase origin/develop

In sync blijven maakt integratie soepeler en houdt je wijzigingen compatibel met wat anderen bouwen.

Reviewen en testen vóór mergen

Hoewel GitFlow direct mergen ondersteunt met commando’s als git flow feature finish, is het beter om pull requests (PR’s) of merge requests (MR’s) te gebruiken voor alle merges naar develop en master.

Voordelen:

• Maakt code review en goedkeuringsworkflows mogelijk
• Triggert geautomatiseerde CI/CD-checks
• Biedt een duidelijke audittrail van wijzigingen

Dit is vooral cruciaal in productieomgevingen waar kwaliteitscontrole telt.

Problemen oplossen met GitFlow

Zelfs met een gestructureerde workflow als GitFlow kunnen er problemen ontstaan, zeker bij teamwork of langlopende branches. 

In dit onderdeel behandelen we de meest voorkomende uitdagingen en hoe je ze effectief oplost.

Merge-conflicten

Merge-conflicten komen vaak voor als je met een groter team aan één codebase werkt en zijn irritant.Ze ontstaan meestal wanneer twee branches dezelfde regels code hebben aangepast.

Stappen om een merge-conflict op te lossen:

1. Stop het git flow finish-proces.
2. Merge de branch handmatig in z’n doel:

git checkout develop
git merge feature/<your-feature>

3. Git vraagt je om conflicten op te lossen. Open de conflicterende bestanden en let op conflictaanduidingen zoals deze:

<<<<<<< HEAD
Code from develop
=======
Code from feature branch
>>>>>>> feature/my-feature

4. Bewerk en ruim de code handmatig op.
5. Markeer de bestanden als opgelost zodra je klaar bent:

git add <resolved-file>

6. Rond de merge vervolgens af met:

git commit -m “resolve merge conflict …”

Verouderde branches opschonen

Soms bevat je repository verouderde feature-, release- of hotfix-branches. Houd je repository zo schoon mogelijk om verwarring te voorkomen.

Je kunt dit oplossen met de onderstaande stappen:

1. Toon alle lokale branches:

git branch

2. Verwijder een lokale branch:

git branch -d <branch-name>

3. Als de branch nog niet is gemerged en je zeker weet dat hij weg kan:

git branch -D <branch-name>

4. Verwijder een remote branch:

git push origin --delete <branch-name>

Het is essentieel om je branches regelmatig te controleren en verouderde branches op te ruimen om je repository zo schoon mogelijk te houden.

Conclusie

GitFlow is een robuust raamwerk voor samenwerking, helderheid en controle in je ontwikkelworkflow. Of je nu aan een soloproject werkt waar meer mensen bij betrokken zijn of bijdraagt aan een groot team, GitFlow helpt je georganiseerd te blijven door feature-ontwikkeling, releases en hotfixes duidelijk te scheiden.

Toen ik GitFlow voor het eerst gebruikte, voelde het als een gamechanger. Geen merge-chaos meer. Niet meer raden welke branch je moet gebruiken. Elk stuk werk had z’n plek, en elke release volgde een herhaalbaar, betrouwbaar proces. In de loop der tijd heb ik GitFlow bij elk team waarmee ik werkte geïntroduceerd. En elke keer zorgde het voor meer structuur, soepelere samenwerking en minder fouten.

In deze tutorial heb je geleerd:

• Wat GitFlow is en waarom het handig is
• Hoe je GitFlow installeert en initialiseert
• Hoe je werkt met features, releases en hotfixes
• Best practices om veelvoorkomende problemen te vermijden
• Hoe je GitFlow aanpast aan moderne workflows met pull requests

Ben je klaar om je Git-workflow naar een hoger niveau te tillen, probeer dan GitFlow in je volgende project. En als je de basis al kent, overweeg dan om het te integreren met de CI/CD-pijplijn van je team, je reviewproces of zelfs GitHub Actions.