SFAgency — Git Workflow Referentie

Inhoud

01 Branch structuur
02 Dagelijkse workflow
03 Conflicten voorkomen
04 Pull Requests
05 Commit berichten
06 Veelvoorkomende scenario's

01 Branch structuur

Gebruik een vaste branch structuur zodat jullie nooit op dezelfde code werken zonder dat dat bewust is.

Branch	Status	Doel
main	Protected	Altijd productie-klaar. Nooit direct op committen. Alleen mergen via PR.
develop	Shared	Integratie branch. Hier komen alle features samen voor ze naar main gaan.
feature/naam	Persoonlijk	Eén feature per branch. Altijd afgesplitst van develop, nooit van main.
fix/naam	Persoonlijk	Bugfixes. Zelfde werkwijze als feature branches.
hotfix/naam	Persoonlijk	Urgente productiefix. Splitsbaar van main, daarna mergen naar main én develop.

💡

Naamgevingsconventie: Gebruik altijd een korte, beschrijvende naam met koppeltekens. Bijvoorbeeld: feature/contact-form, fix/mobile-nav-overflow, hotfix/broken-checkout.

02 Dagelijkse workflow

Volg deze stappen elke keer als je begint aan een nieuw stuk werk. Dit is de kern van conflict-vrij samenwerken.

Haal de laatste wijzigingen op

Start elke werkdag hiermee. Dit zorgt dat jouw lokale develop altijd up-to-date is.

start van de dag

# Ga naar develop en haal alles op
git checkout develop
git pull origin develop

Maak een nieuwe feature branch aan

Nooit direct op develop werken. Elke taak of feature krijgt zijn eigen branch vanuit develop.

nieuwe branch

# Maak een nieuwe branch en wissel er direct naartoe
git checkout -b feature/jouw-feature-naam

Werk en commit regelmatig

Maak kleine, gerichte commits. Eén commit = één logische wijziging. Zorg dat de app na elke commit nog werkt.

commit

git add .
git commit -m "feat: voeg contactformulier toe"

Rebase op develop vóór je pusht

Dit is de sleutelstap. Voordat je je werk deelt, synchroniseer je altijd eerst met de laatste develop. Dit is wat merge conflicten op de remote voorkomt.

rebase — altijd doen vóór pushen

# 1. Haal de laatste develop op
git checkout develop
git pull origin develop

# 2. Ga terug naar je branch en rebase op develop
git checkout feature/jouw-feature-naam
git rebase develop

# Als er conflicten zijn: los ze op, daarna:
git add .
git rebase --continue

Push je branch naar GitHub

Na de rebase is je branch up-to-date en klaar om te pushen.

push

git push origin feature/jouw-feature-naam

# Na een rebase heb je mogelijk --force-with-lease nodig
git push --force-with-lease origin feature/jouw-feature-naam

Open een Pull Request naar develop

Open een PR op GitHub. De andere developer reviewt het kort en mergt het. Daarna verwijder je de feature branch.

03 Conflicten voorkomen

Merge conflicten ontstaan bijna altijd door dezelfde oorzaken. Hier zijn de regels die ze systematisch voorkomen.

✓

Sync dagelijks. Haal elke ochtend de laatste develop op, ook als je geen nieuwe branch begint. Kleine verschillen zijn makkelijker te resolven dan grote.

✓

Kleine, korte branches. Een feature branch mag maximaal 2–3 dagen leven. Hoe langer je branch leeft, hoe groter het divergentie-risico. Splits grote features op in kleinere stukken.

✓

Communiceer wie waar aan werkt. Maak in Slack of een taakbord altijd bekend op welk bestand of onderdeel je werkt. Werk jullie nooit tegelijk in hetzelfde component of dezelfde pagina?

✓

Gebruik rebase in plaats van merge voor het bijwerken van je branch. git rebase develop geeft een lineaire geschiedenis en minder conflicten dan git merge develop.

Nooit rechtstreeks op main of develop pushen. Altijd via een PR. Zo blijft develop altijd in een werkende staat.

Lock-files beheren. package-lock.json is een bekende conflictbron. Spreek af wie na een npm install de lock-file pusht, of resolve het conflict door één versie te committen en opnieuw npm install te draaien.

✗

Nooit git push --force op gedeelde branches (develop, main). Alleen --force-with-lease is toegestaan op je eigen feature branch na een rebase.

04 Pull Requests

PRs zijn de enige manier waarop code in develop en main terechtkomt. Houd het simpel.

PR aanmaken

✓

Eén PR per feature of fix. Niet meerdere ongerelateerde wijzigingen in één PR stoppen.

✓

Schrijf een korte beschrijving van wat er is veranderd en waarom. Zo kan de ander snel reviewen.

✓

Rebase op develop voordat je de PR opent — nooit een PR openen met een branch die achterloopt op develop.

Mergen

💡

Squash & Merge is de aanbevolen methode voor feature branches. Dit houdt de develop history schoon: één commit per feature in plaats van tientallen kleine commits.

na het mergen — branch opruimen

# Verwijder de remote branch na het mergen
git push origin --delete feature/jouw-feature-naam

# Verwijder de lokale branch
git checkout develop
git pull origin develop
git branch -d feature/jouw-feature-naam

Van develop naar main

Wanneer develop stabiel is en je wil deployen naar productie, open je een PR van develop naar main. Vercel deployt automatisch zodra main geüpdatet is.

05 Commit berichten

Gebruik de Conventional Commits standaard. Dit maakt de git history leesbaar en makkelijk doorzoekbaar.

formaat

type(scope): korte beschrijving in de gebiedende wijs

Type	Wanneer gebruiken	Voorbeeld
feat	Nieuwe functionaliteit	feat: voeg dark mode toe
fix	Bugfix	fix: herstel overflow in mobile nav
style	CSS / opmaak, geen logica	style: pas button radius aan
refactor	Code herstructureren zonder gedrag te wijzigen	refactor: extraheer reusable Card component
chore	Dependencies, configs, tooling	chore: update next.js naar 15.2
docs	Documentatie	docs: update README met deploy instructies

06 Veelvoorkomende scenario's

Je collega heeft develop geüpdatet terwijl jij aan het werk bent

rebase je branch op de nieuwe develop

# Haal de nieuwste develop op
git fetch origin

# Rebase je huidige branch
git rebase origin/develop

# Push met force-with-lease (safe force push)
git push --force-with-lease origin feature/jouw-branch

Er is toch een merge conflict

conflict oplossen tijdens rebase

# Git stopt bij een conflict en toont welke bestanden
git status

# Open het bestand, zoek naar <<<<<<< HEAD
# Kies de juiste versie, verwijder de conflict-markers
# Sla op, voeg toe aan staging
git add <bestand>

# Ga verder met de rebase
git rebase --continue

# Wil je de rebase afbreken en terugzetten?
git rebase --abort

Je zit op de verkeerde branch aan het werk

werk verplaatsen naar nieuwe branch

# Sla je werk op in stash
git stash

# Ga naar develop en maak de juiste branch
git checkout develop
git pull origin develop
git checkout -b feature/juiste-branch-naam

# Haal je werk terug uit de stash
git stash pop

Snelle productiefix (hotfix)

hotfix workflow

# Splijs van main (productie)
git checkout main
git pull origin main
git checkout -b hotfix/beschrijving

# Fix, commit, push, PR naar main
git commit -m "hotfix: repareer broken checkout redirect"
git push origin hotfix/beschrijving

# Na merge naar main: ook mergen naar develop!
git checkout develop
git merge main
git push origin develop

⚠️

Vergeet niet: Na een hotfix naar main altijd ook develop updaten. Anders krijg je de bug terug bij de volgende release vanuit develop.

Overzicht van je branches

handy commands

# Alle branches zien (lokaal + remote)
git branch -a

# Alle remote branches ophalen zonder te mergen
git fetch --all --prune

# Bekijk de laatste commits per branch
git log --oneline --graph --all -20

# Oude gemergede branches verwijderen
git branch --merged develop | grep -v "^\*\|develop\|main" | xargs git branch -d