Cursus
Geavanceerd Git
3 Hr
7.1K
Als je ooit naar een rommelige Git-historie hebt zitten staren en je afvroeg welke commits nu echt belangrijk zijn, is het tijd om het verschil tussen rebase en merge te leren.
De twee primaire strategieën voor branch-integratie in Git—merge en rebase—dienen fundamenteel verschillende doelen in je ontwikkelworkflow. Je keuze heeft direct invloed op de efficiëntie van code reviews, debug-sessies en de onderhoudbaarheid van je project op de lange termijn. De verkeerde aanpak kan je commitgeschiedenis onleesbaar maken of belangrijke samenwerkingscontext verwijderen die je team nodig heeft.
In deze gids leer je wanneer je welke strategie gebruikt, hoe ze conflicten verschillend afhandelen en hoe je hybride workflows implementeert die het beste van beide werelden bieden.
TL;DR: Git rebase vs Git merge
Op zoek naar een snel antwoord?
- Git merge behoudt de volledige ontwikkelgeschiedenis door nieuwe commits te maken die branches combineren zonder bestaande commits te wijzigen.
- Git rebase herschrijft de historie door commits van de ene branch boven op een andere branch opnieuw af te spelen, wat een lineair verhaal oplevert maar de commit-SHA’s verandert.
Gebruik merge voor samenwerking en audittrails, en rebase voor schone, private branch-ontwikkeling.
Lees verder voor meer!
De kernconcepten begrijpen
Voordat je de juiste integratiestrategie kunt kiezen, is het belangrijk om te begrijpen hoe elke methode fundamenteel werkt. Laten we de kernmechanismen van beide benaderingen uiteenzetten.
Git merge begrijpen
Git merge werkt als een niet-destructief integratiemechanisme dat de volledige ontwikkelgeschiedenis van je project bewaart. Wanneer je branches mergen, maakt Git een nieuwe commit die de wijzigingen van beide branches combineert zonder de bestaande commits te veranderen.
Deze aanpak blinkt uit in samenwerkende omgevingen waar meerdere ontwikkelaars tegelijk aan dezelfde codebase werken. Je ziet precies wanneer features zijn ontwikkeld, wie waaraan werkte en hoe verschillende branches in de loop van de tijd evolueerden.
Projecten die gevoelig zijn voor audits profiteren van de transparantie van git merge. Financiële software, medische toepassingen en andere gereguleerde sectoren vereisen vaak volledige traceerbaarheid van codewijzigingen voor compliance-doeleinden.
Het commando gebruikt een three-way merge-algoritme dat de gemeenschappelijke voorouder van beide branches vergelijkt met de huidige staat van elke branch. Dit creëert merge-commits die als knooppunten in je commitgrafiek dienen en laten zien waar branches zijn samengekomen.
Kortom, het behoudt waardevolle context, maar vergroot ook de visuele complexiteit van je projectgeschiedenis.
# On main, bring in feature-xyz:
git checkout main
git merge feature
# ➜ Creates a merge commit:
# * Merge branch 'feature'
# |\
# | * feature change 1
# | * feature change 2
# * | hotfix on main
# |/
# * initial commit
Afbeelding 1 - Git-projectgeschiedenis na een git merge-actie.
> Wil je meer leren over Git merge? Lees gerust onze uitgebreide gids.
Git rebase begrijpen
Git rebase herschrijft je commitgeschiedenis door commits van de ene branch te nemen en die boven op een andere branch opnieuw af te spelen. In plaats van merge-commits te maken, verplaatst rebase je volledige featurebranch zodat die vanaf de nieuwste commit van je doelbranch begint.
Dit proces houdt historische revisie in, waarbij Git je commits tijdelijk verwijdert, de basisbranch bijwerkt en vervolgens je wijzigingen één voor één opnieuw toepast. Elke commit krijgt een nieuwe SHA-hash en vormt effectief nieuwe commits met dezelfde wijzigingen maar andere ouderrelaties.
Rebase gaat met fijnere korrelgrootte met conflicten om dan merge. In plaats van alle conflicten in één keer op te lossen, kom je ze commit voor commit tegen en los je ze op terwijl Git je wijzigingen afspeelt.
Deze aanpak werkt uitzonderlijk goed voor private branches waarop jij de enige ontwikkelaar bent. Je kunt je commitgeschiedenis opschonen, gerelateerde commits samenvoegen en een gepolijste reeks wijzigingen aan je team presenteren.
Het rebasen van publieke branches waarop anderen hun werk hebben gebaseerd kan echter serieuze coördinatieproblemen creëren en dubbele commits in je gedeelde historie introduceren.
# Bring your feature branch up to date:
git checkout feature
git rebase main
# If you want to squash or reorder:
git rebase -i main
# → opens editor with:
# pick abc123 Feature commit 1
# pick def456 Feature commit 2
# Change to:
# pick abc123 Feature commit 1
# squash def456 Feature commit 2
Afbeelding 2 - Git-projectgeschiedenis na een git rebase-actie.
> Ben je beginner? Deze Git rebase-gids helpt je snel op weg.
Gevolgen voor workflows en branchbeheer
Je keuze tussen merge en rebase bepaalt hoe je hele team samenwerkt en code-integratie beheert. Elke strategie creëert duidelijke ontwikkelpatronen die alles beïnvloeden, van dagelijkse workflows tot langdurig projectonderhoud.
Laten we beide dieper verkennen.
Merge-centrische ontwikkelpatronen
Teams met merge-zware workflows leggen doorgaans de nadruk op feature-isolatie en periodieke integratiecycli. Ontwikkelaars maken featurebranches, werken dagen of weken zelfstandig en mergen hun afgeronde werk daarna in één grote update terug naar de main-branch.
Dit patroon moedigt aan om hele features af te ronden vóór integratie. Je ziet vaak dat teams regelmatige “integratiedagen” plannen waarop meerdere featurebranches tegelijk worden gemerged. De aanpak werkt goed voor teams die een duidelijke scheiding tussen ontwikkelfases en integratiefases prefereren.
Merge-centrische workflows leiden, naarmate het team groeit, vaak tot complexere commitgrafieken, waarbij meerdere merge-commits een webachtige structuur vormen die het lastig kan maken om de evolutie van specifieke features te volgen. Toch komt die complexiteit met het voordeel van het behouden van de volledige context van hoe features zijn ontwikkeld en geïntegreerd.
Het branchingmodel creëert natuurlijke controlepunten waarmee je eenvoudig hele features kunt terugdraaien zonder ander werk te beïnvloeden. Dit vangnet spreekt teams aan die aan mission-critical applicaties werken, waar stabiliteit belangrijker is dan snelheid.
> Wist je dat je merge-commits kunt terugdraaien? Onze Git revert-gids vol voorbeelden laat zien hoe.
Rebase-georiënteerde ontwikkelpatronen
Teams die focussen op rebase hanteren continu rebasen, waarbij ontwikkelaars hun featurebranches regelmatig bijwerken met de nieuwste wijzigingen uit de main-branch. In plaats van te wachten tot een feature af is, rebasen teamleden hun werk meerdere keren per dag om bij te blijven.
Deze teams leggen veel nadruk op commits samenvoegen (squashen) en het cureren van historie. Voordat werk wordt gemerged, combineren ontwikkelaars gerelateerde commits, herschrijven ze commitberichten voor duidelijkheid en zorgen ze dat hun branch een coherent verhaal vertelt van de ontwikkeling van de feature.
Het Linux-kernelproject is hét perfecte voorbeeld van effectieve rebase-toepassing op enorme schaal. Met duizenden bijdragers wereldwijd houdt het project een opmerkelijk schone commitgeschiedenis aan via strikte rebase-standaarden. Linus Torvalds zelf pleit voor het rebasen van featurebranches vóór indiening, met het argument dat een gecureerde historie debuggen en code review aanzienlijk efficiënter maakt.
Rebase-georiënteerde teams rapporteren vaak snellere code-reviewcycli omdat reviewers een logische opeenvolging van wijzigingen kunnen volgen in plaats van de chronologische chaos van gezamenlijke ontwikkeling te ontrafelen.
> Ben je een beginner die zijn repo’s netjes wil houden? Git clean is alles wat je nodig hebt.
Wat is het grootste verschil tussen git rebase en git merge?
Wanneer moet ik git merge gebruiken in plaats van git rebase?
Wanneer moet ik git rebase gebruiken in plaats van git merge?
Kan ik zowel git merge als git rebase in hetzelfde project gebruiken?
Wat gebeurt er als ik een publieke branch rebase waar anderen aan werken?
Onderwerpen
