Git Merge vs Rebase: welke strategie houdt je team uit de problemen?

By Mirko Peters · 2026-10-27

Ontdek de belangrijkste verschillen tussen Git merge en rebase. Leer de gouden regel van rebasen om de codegeschiedenis van je team veilig en overzichtelijk te houden.

Automatically translated with AI from the original post. Read the English original

Bij het samenbrengen van code in Git bepaalt de keuze tussen merge en rebase hoe de projectgeschiedenis wordt bewaard en of je het werk van teamgenoten dreigt te overschrijven. Met merge blijft een volledig historisch overzicht behouden via merge-commits. Rebasen levert een schone, lineaire geschiedenis op doordat je commits naar de top van de main-branch worden verplaatst. Dat is een gevaarlijke zet als je het op gedeelde branches toepast.

Belangrijkste punten

• Merge bewaart precies de geschiedenis van wanneer en hoe codebranches zijn samengevoegd, via een aparte merge-commit.
• Rebase herschrijft de commitgeschiedenis tot een schone, rechte tijdlijn zonder rommelige merge-commits.
• Rebase nooit een gedeelde branch waar andere ontwikkelaars actief aan werken. Anders breek je hun lokale kopieën en dwing je destructieve overschrijvingen af.
• Gebruik rebase uitsluitend op je eigen privé, lokale branches om rommelige commits op te schonen voordat je een pull request publiceert.
• Twijfel je in een samenwerkingsproject, kies dan voor merge. Dat is de veiligste manier om één gedeelde versie van de waarheid te behouden.

De werking van Git merge begrijpen

Merge is het fundamentele vangnet van samenwerkend ontwikkelen. Wanneer je klaar bent met een feature-branch en je pull request is goedgekeurd, combineert merge je wijzigingen met de main-branch door een gloednieuwe merge-commit aan te maken. Deze commit legt expliciet vast op welk exact moment twee verschillende geschiedenissen samenkwamen.

Het grote voordeel van deze aanpak is volledige transparantie. Er wordt niets herschreven en niets gaat verloren. Als er weken later een bug ontstaat, laat het commitlogboek duidelijk zien dat een bepaalde feature-branch op een bepaalde dinsdag is gemerged. Voor teams die auditbaarheid en absolute veiligheid belangrijker vinden dan een keurig grafiekje, is merge de standaardwerkwijze.

De voordelen en risico's van Git rebase

Rebase kiest een fundamenteel andere weg. In plaats van de chronologische afsplitsing van je feature-branch te bewaren, tilt rebase je commits van hun oorspronkelijke startpunt en plaatst ze netjes bovenop de nieuwste versie van de main-branch. Daarbij worden nieuwe commits aangemaakt, wat een strakke, lineaire geschiedenis oplevert die eruitziet alsof iedereen na elkaar heeft gewerkt.

Veel ontwikkelaars houden van deze overzichtelijke weergave, omdat het doorlezen van de projectgeschiedenis eenvoudig wordt zonder kriskrasmerglijnen. Toch heeft deze esthetiek een serieus operationeel nadeel. Omdat rebase de geschiedenis letterlijk herschrijft, verandert het de commit-identifiers. Pas je dit toe op een branch die iemand anders al naar zijn lokale machine heeft gehaald, dan loopt zijn versie van de werkelijkheid meteen uiteen van de jouwe.

De gouden regel van Git rebase

De belangrijkste regel in het dagelijks gebruik van Git is simpel: rebase nooit een branch waar andere mensen aan werken. Voordat je een rebase-commando uitvoert, moet je één cruciale vraag stellen: kijkt of bouwt er nog iemand anders op deze branch?

Is het antwoord ja, stop dan meteen en gebruik in plaats daarvan een merge. Wie toch rebaset en de herschreven wijzigingen vervolgens naar de remote pusht, breekt de lokale kopieën van zijn teamgenoten. Bij pushen of pullen gooit Git dan enorme conflicten op, wat vaak leidt tot een destructieve force-push die per ongeluk uren nauwgezet werk van collega's kan wissen.

Veilige werkwijzen voor rebase

Rebasen is op zich niet slecht; het wordt alleen verkeerd gebruikt wanneer je het buiten het bedoelde toepassingsgebied inzet. De ideale plek voor rebase is je eigen lokale, privé-featurebranch, voordat je een pull request opent voor openbare review.

Als je tijdens het opsporen van een hardnekkige bug tientallen rommelige, kleine commits hebt gemaakt, zoals "typo gefixt", "nog eens proberen" en "oeps puntkomma vergeten", dan laat rebase je die commits samenvoegen en herordenen tot een samenhangend verhaal. Zodra je privébranch netjes is, push je die, open je je pull request en laat je het gezamenlijke reviewproces veilig verlopen via een standaard merge.

Conclusie

Als je de nuances van mergen en rebasen beheerst, voorkom je catastrofaal dataverlies en houd je de wrijving in het team tot een absoluut minimum. Door te begrijpen wanneer je de historische context bewaart en wanneer je een schone, lineaire tijdlijn aanhoudt, verloopt je ontwikkelworkflow soepel en efficiënt. Wil je meer fundamentele concepten verkennen en meer leren over bredere deploymentstrategieën? Luister naar de volledige aflevering van de podcast voor een diepgaande, jargonvrije uitleg.

Veelgestelde vragen

Wat gebeurt er tijdens een Git-merge?

Een Git-merge neemt twee uiteenlopende branchgeschiedenissen en voegt ze weer samen door een nieuwe mergecommit aan te maken. Zo blijft de oorspronkelijke geschiedenis van beide branches behouden zonder dat bestaande commit-hashes veranderen.

Waarom wordt rebasen als gevaarlijk beschouwd op gedeelde branches?

Rebasen herschrijft de commitgeschiedenis door nieuwe commit-hashes te genereren. Als andere ontwikkelaars aan dezelfde branch werken, komen hun lokale kopieën niet meer overeen met de externe repository, wat leidt tot ernstige conflictfouten en mogelijk dataverlies.

Wanneer kan ik git rebase veilig gebruiken?

Gebruik git rebase uitsluitend op je eigen lokale, privé-featurebranches, om rommelige commitberichten op te schonen of om de laatste wijzigingen uit main binnen te halen voordat je een pull request opent.

Zorgt mergen voor extra commits?

Ja, mergen voegt meestal een mergecommit toe aan de projectgeschiedenis om het exacte moment vast te leggen waarop de featurebranch in de main-branch is opgenomen.