Rebasen: wat is het, hoe werkt rebase en werken met Git

Wat is rebase in Git

Rebase — is een Git-commando dat de huidige branch herbaset op de opgegeven branch: het neemt alle commits van de huidige branch, slaat ze tijdelijk op, verplaatst de branch-pointer naar de doelcommit en past de opgeslagen commits sequentieel erboven toe. Het resultaat — de geschiedenis ziet eruit alsof de ontwikkelaar direct vanaf de laatste commit van de doelbranch heeft gewerkt.

Basis syntaxis: git rebase main — terwijl je in de feature-branch bent, verplaatst dit commando alle feature-commits naar de top van main. Git gebruikt een three-way merge-strategie voor elke commit afzonderlijk. Als commit A al aanwezig is in de doelbranch (bepaald via hash), slaat Git deze automatisch over, wat duplicatie van wijzigingen voorkomt.

Rebase ondersteunt ook de onto-modus voor het verplaatsen van een deel van de commits: git rebase --onto target start end — deze vorm maakt het mogelijk een reeks commits uit een branch te halen en deze bovenop een andere toe te passen. Bijvoorbeeld git rebase --onto main feature~3 feature verplaatst de laatste drie commits van de feature-branch naar de top van main.

# Schakel naar feature-branch
git checkout feature

# Herbaseer feature op main
git rebase main

# Na succesvolle rebase — geschiedenis is lineair
git log --oneline --graph

# Verplaats laatste 3 commits naar main
git rebase --onto main HEAD~3 HEAD

Rebase vs Merge: belangrijkste verschillen

Rebase en merge lossen dezelfde taak op — het combineren van wijzigingen uit verschillende branches — maar doen dit op fundamenteel verschillende manieren. Merge behoudt de volledige samenvoeggeschiedenis door een merge-commit met twee ouders te maken. Rebase herschrijft de geschiedenis en maakt deze lineair. De keuze hangt af van de workflow van het team en de regels voor het werken met de repository.

Het belangrijkste verschil — hoe het feit van samenvoegen wordt vastgelegd. Merge bewaart: „op dit punt hebben we feature in main samengevoegd” — dit is informatief voor de projectgeschiedenis, maar vervuilt de log bij frequente samenvoegingen. Rebase toont: „feature-commits zijn sequentieel gemaakt vanaf de laatste staat van main” — dit is schoon, maar verbergt het feit dat het werk parallel werd uitgevoerd.

Het tweede verschil — afhandeling van conflicten. Bij merge worden conflicten eenmalig opgelost en de oplossing wordt vastgelegd in de merge-commit. Bij rebase kunnen conflicten ontstaan voor elke verplaatste commit en elke vereist een afzonderlijke oplossing. Dit is arbeidsintensiever, maar geeft meer controle over welke wijzigingen in de uiteindelijke versie terechtkomen.

Interactieve rebase: commando’s en vlaggen

Interactieve rebase (git rebase -i) — is een modus waarin Git een editor opent met een lijst van commits en beschikbare acties voor elk ervan. De ontwikkelaar kan de geschiedenis herschrijven voordat deze naar de externe repository wordt gestuurd. Dit is het belangrijkste hulpmiddel voor het schoonhouden van commits in een feature-branch.

Beschikbare commando’s in de interactieve modus: pick (laat de commit zoals hij is), reword (wijzig het commit-bericht), edit (stop voor wijzigingen), squash (voeg samen met de vorige commit, behoud beide berichten), fixup (voeg samen, verwijder het bericht), drop (verwijder de commit). Elk commando wordt voor de commit-hash in de geopende editor geplaatst.

Squash en fixup — de meest gebruikte commando’s voor het combineren van commits. Als een ontwikkelaar 5 kleine commits met correcties heeft gemaakt tijdens het werk, zal squash ze combineren in één logische commit met een betekenisvol bericht. Fixup is handig voor het corrigeren van typefouten: wijzigingen worden aan de vorige commit toegevoegd zonder hun eigen bericht te bewaren.

# Open editor voor laatste 4 commits
git rebase -i HEAD~4

# Editor zal tonen:
pick a1b2c3d Add authentication
pick e4f5g6h Fix typo in login
squash i6j7k8l Additional login fixes
pick m9n0o1p Add auth tests

# Na opslaan — Git voert rebase uit
# en opent editor voor samengevoegd commit-bericht

# Auto-squash zonder editor te openen
git rebase -i HEAD~4 --autosquash

De vlag --autosquash stelt automatisch fixup/squash in voor commits waarvan de berichten beginnen met fixup! of squash!. Dit versnelt het werk als de ontwikkelaar commits van tevoren markeert voor latere samenvoeging. De vlag --committer-date-is-author-date behoudt de originele datum van de commit bij rebasen — handig voor het behouden van chronologie in de geschiedenis.

Conflicten oplossen bij rebase

Conflicten bij rebase ontstaan wanneer Git de verplaatste commit niet automatisch kan toepassen vanwege tegenstrijdigheden met wijzigingen in de doelbranch. In tegenstelling tot merge, waar het conflict eenmalig wordt opgelost, kan bij rebase elke commit een conflict veroorzaken en moet dit sequentieel worden opgelost voor elke commit van de oudste naar de nieuwste.

Wanneer een conflict optreedt, onderbreekt Git de rebase en meldt welke commit het probleem heeft veroorzaakt. De ontwikkelaar opent het conflicterende bestand (Git markeert conflictgebieden met markeringen <<<<<<<, =======, >>>>>>>), bewerkt het, voegt het toe aan de index (git add) en zet de rebase voort met het commando git rebase --continue. Als er geen oplossing wordt gevonden — git rebase --abort annuleert de rebase volledig.

Tip: bij meerdere conflicten is het efficiënter om git mergetool te gebruiken, dat een visuele editor opent voor het oplossen van tegenstrijdigheden. Je kunt ook de problematische commit overslaan (git rebase --skip), maar dit verwijdert de wijzigingen uit de uiteindelijke geschiedenis, wat zelden de juiste oplossing is.

# Start rebase met conflict
git rebase main
# Auto-merging file.txt
# CONFLICT (inhoud): Samenvoegconflict in file.txt

# Controleer status
git status
# beide gewijzigd: file.txt

# Bewerk conflicterende secties → git add → ga verder
git add file.txt
git rebase --continue

# Bij twijfel — annuleer
git rebase --abort

Wanneer mag je geen rebase doen

Gouden regel van rebase: herbaset nooit commits die al naar de externe repository zijn gestuurd en beschikbaar zijn voor andere ontwikkelaars. Omdat rebase de hashes van commits herschrijft, zullen collega’s conflicten ondervinden bij synchronisatiepogingen — hun lokale geschiedenis zal niet overeenkomen met de herschreven externe geschiedenis.

De situatie waarin rebase categorisch verboden is: als iemand al een branch heeft gemaakt op basis van jouw commits (bijvoorbeeld je collega heeft een feature gemaakt van jouw feature), zal het wijzigen van de geschiedenis zijn werk verpesten. In dergelijke gevallen moet merge worden gebruikt. Ook wordt afgeraden om rebase vlak voor een deadline te doen — een fout bij het oplossen van conflicten kan langer duren dan verwacht en de release blokkeren.

Uitzondering: als de branch slechts door één ontwikkelaar wordt gebruikt (persoonlijke feature-branch, niet gepubliceerd of gepubliceerd in draft-modus), is rebase vóór push standaard praktijk. Na publicatie en het begin van teamwerk — alleen merge. GitHub en GitLab bieden standaard squash merge als compromis: het combineert commits in één, maar herschrijft de geschiedenis van de doelbranch niet.

• Openbare branches (main, develop, release) — rebase volledig verboden.
• Andermans commits — als de branch commits van een andere ontwikkelaar bevat, is rebase ontoelaatbaar.
• Voor een release — het risico op conflicten is hoger: merge is veiliger een dag voor de deadline.
• Branches met tags — het verplaatsen van een commit met een tag schendt de conventies van semantisch versiebeheer.
• CI/CD gekoppeld aan hashes — sommige deploy-systemen identificeren builds aan de hand van de commit-hash; rebase verbreekt de tracking.

Praktische workflow met rebase

In moderne teams wordt meestal de rebase-gerichte workflow gebruikt in combinatie met GitHub Flow. Het proces ziet er als volgt uit: de ontwikkelaar maakt een feature-branch vanaf main, werkt erin, synchroniseert periodiek via git rebase main en voert vóór het aanmaken van een pull request een interactieve rebase uit om de geschiedenis op te schonen.

Na het aanmaken van een PR (als er nieuwe wijzigingen uit main moeten worden gehaald) wordt git pull --rebase main gebruikt in plaats van de gewone git pull. Dit maakt het mogelijk wijzigingen binnen te halen zonder een overbodige merge-commit te maken. Git pull met de --rebase vlag is gelijk aan git fetch + git rebase — Git laadt eerst nieuwe commits, dan herbaset het lokale wijzigingen erbovenop.

Git biedt de mogelijkheid om rebase in te stellen als standaardgedrag voor pull: git config --global pull.rebase true. Na deze configuratie voert git pull altijd rebase uit in plaats van merge. Als een gewone pull nodig is — wordt git pull --no-rebase gebruikt. Veel teams schakelen ook autostash in: git config --global rebase.autoStash true — dit verbergt automatisch niet-gecommitte wijzigingen vóór rebase en herstelt ze daarna.