Git Flow Branching Strategie

Overzicht

Bij Innovative365 gebruiken we de Git Flow branching strategie waar mogelijk.

Kernprincipes

Twee hoofdbranches:
- main - bevat productie-ready code
- develop - integratie branch voor nieuwe ontwikkelingen
Ondersteunende branches:
- feature/* - voor het ontwikkelen van nieuwe functionaliteiten
- release/* - voor het voorbereiden van een nieuwe release
- hotfix/* - voor kritieke fixes die direct naar productie moeten

Rebasing vs. Merging

De develop branch is protected en vereist dat feature branches worden gerebased voordat ze worden geïntegreerd.

Voordelen van Rebasing

Creëert een schone, lineaire commit-geschiedenis
Voorkomt onnodige merge commits
Vergemakkelijkt het traceren van wijzigingen
Maakt het terugdraaien van specifieke wijzigingen eenvoudiger

Rebase Workflow

Rebase Commando's

Rebase Commando's Update je develop branch:

git checkout develop
git pull origin develop

Rebase je feature branch:

git checkout feature/mijn-feature git rebase develop

Bij conflicten:

Los conflicten op in je editor

git add .
git rebase --continue

Force push naar je remote feature branch:

git push --force-with-lease origin feature/mijn-feature

Best Practices

Gebruik het Conventional Commits patroon voor duidelijke, gestructureerde commit messages:
- feat: - voor nieuwe functionaliteiten
- fix: - voor bugfixes
- docs: - voor documentatie wijzigingen
- style: - voor code style wijzigingen (formatting, etc.)
- refactor: - voor code wijzigingen die geen bugs fixen of features toevoegen
- perf: - voor performance verbeteringen
- test: - voor het toevoegen of corrigeren van tests
- chore: - voor wijzigingen in build processen of tools
- wip: - voor werk in uitvoering
- clean: - voor code opschoning
Bij het oplossen van merge conflicten gebruik de volgende conventie in je commit message:
- merge: resolve conflicts in [bestandsnaam/module]
- Voeg details toe over hoe de conflicten zijn opgelost als dit niet triviaal was
Rebase je feature branch regelmatig op develop om conflicten vroeg te detecteren
Gebruik altijd --force-with-lease in plaats van --force voor veiligere pushes
Vermijd rebasing op branches die al met teamgenoten gedeeld zijn zonder afstemming
Start feature branches altijd vanaf de meest recente develop versie

Branch Policies

Op de develop branch zijn de volgende regels/richtlijnen van toepassing:

Pull requests zijn verplicht voor alle wijzigingen
Code review door ten minste één teamlid is vereist
Branches moeten up-to-date zijn met develop voordat ze kunnen worden gemerged
Automatische tests moeten succesvol zijn voordat de PR kan worden goedgekeurd

Werken met Pull Requests

Zorg dat je feature branch gerebased is op develop
Maak een Pull Request aan naar develop via GitHub
Wacht op de code review en CI/CD checks
Verwerk feedback indien nodig met nieuwe commits
Rebase opnieuw wanneer er wijzigingen in develop zijn
Wanneer alles is goedgekeurd, wordt de PR gemerged

Veel voorkomende Git commando's

# Een nieuwe feature branch aanmaken
git checkout develop
git pull origin develop
git checkout -b feature/nieuwe-functionaliteit

# Lokale wijzigingen committen met Conventional Commits
git add .
git commit -m "feat: implementeer login functionaliteit"
git commit -m "fix: corrigeer validatie in formulier"
git commit -m "docs: voeg API documentatie toe"

# Feature branch pushen naar remote
git push origin feature/nieuwe-functionaliteit

# Branch updaten na remote changes
git pull --rebase origin feature/nieuwe-functionaliteit

# Stashing gebruiken voor tijdelijke wijzigingen
git stash
git stash pop

Last modified: 23 March 2026