Welke werkpatronen met Git heb je gebruikt?

Git-flow: Gebruikt voor projecten met een duidelijk gedefinieerde releasecyclus. Handig voor het beheren van functionaliteitsfixes, bugfixes en releasevoorbereidingen. Maakt takken aan: feature, develop, release, hotfix, master.
GitHub flow: Toegepast voor projecten waar frequente, kleine releases prioriteit hebben. Eenvoudig model gebaseerd op één hoofdbranch (main of master) en takken voor elke feature of fix, die direct na review worden gemerged.
Trunk-based development: Gepraktiseerd voor projecten die een hoge frequentie van integratie en continue deployment vereisen. Ontwikkelaars brengen wijzigingen direct aan in de hoofdbranch (trunk) of korte levensduur takken, die snel worden teruggemerged. Belangrijk element — Feature Toggles.

Naast deze hoofdpatronen, werd gebruikt:

Rebase vs Merge: Afhankelijk van de situatie en teamafspraken, werd git rebase gebruikt om een schone geschiedenis van commits te behouden op lokale takken vóór het mergen, en git merge --no-ff om een expliciete merge-geschiedenis te behouden.

# Voorbeeld rebase
git checkout feature/nova-functie
git pull --rebase origin main 
# Conflictoplossing indien nodig
git push -f origin feature/nova-functie 
# Of pull request voor merge in main

# Voorbeeld merge --no-ff
git checkout main
git merge --no-ff feature/nova-functie -m "Merge feature/nova-functie in main"
git push origin main

Squash and Merge: Vaak toegepast bij het samenvoegen van feature takken in de hoofdbranch via Pull Request. Hiermee kunnen meerdere commits uit de feature tak worden samengevoegd tot één schone commit in de hoofdbranch.
```
# Voorbeeld squash merge via Git-platform (GitHub, GitLab)
# Wordt meestal gedaan bij het bevestigen van de Pull Request.
```
Cherry-picking: Gebruikt om specifieke commits tussen takken over te zetten, bijvoorbeeld voor backporting van fixes van de hoofdbranch naar de release- of staging-branch.
```
# Voorbeeld cherry-pick
git checkout release/v1.2
git cherry-pick <commit_hash>
```