Rebase: wat is het, verschil met Merge en werkingsprincipe

Wat is Rebase?

Rebase (herbaseren) — is een Git-bewerking die commits van de huidige branch naar een nieuw referentiepunt (basis) verplaatst. In plaats van een merge-commit te maken, neemt rebase elke commit uit de bronbranch en past deze achtereenvolgens bovenop de nieuwe basis toe. Het resultaat is een lineaire reeks commits zonder vertakkingen.

De naam rebase komt van „re-base" — de basis wijzigen. Als merge twee branches op één punt samenvoegt, verplaatst rebase feitelijk je hele branch naar een nieuwe locatie, waardoor de illusie ontstaat dat je bent begonnen vanaf de actuele toestand van de doelbranch. Dit creëert de schijn van perfect sequentieel werk.

Volgens Atlassian, 2025 besteden teams die rebase gebruiken voor feature-branches 30% minder tijd aan het analyseren van de commitgeschiedenis in vergelijking met teams die uitsluitend merge gebruiken. Lineaire geschiedenis vereenvoudigt git blame, bisect en het bekijken van het log via git log --oneline.

Fundamenteel verschil met Merge

Merge voegt branches samen door een commit met twee ouders te maken. Rebase herschrijft de geschiedenis: nieuwe commits worden opnieuw aangemaakt met nieuwe hashes, hoewel de wijzigingen erin identiek zijn aan de originele. Dit betekent dat rebase de SHA-identificatie van commits verandert, wat kritiek is voor openbare branches.

Hoe werkt Rebase

Het mechanisme van rebase bestaat uit vier stappen: Git bepaalt de gemeenschappelijke voorouder (merge base) van de huidige en doelbranch, en past vervolgens elke commit van de huidige branch achtereenvolgens bovenop de doelbranch toe. Als er bij een stap een conflict optreedt, stopt rebase en wacht op een oplossing.

# Beginsituatie: feature loopt 3 commits achter op develop
git checkout feature/new-login
git rebase develop

# Git neemt 3 commits uit feature en past ze toe op develop
# Als er geen conflicten zijn — rebase wordt automatisch voltooid
# Als die er zijn — Git stopt bij de conflictueuze commit

Na rebase bevat de feature-branch alle commits uit develop plus zijn eigen commits, die eruitzien als een voortzetting van develop. Dit maakt het mogelijk om via fast-forward in develop te mergen zonder een merge-commit te maken.

Stapsgewijs proces

Laten we een gedetailleerd voorbeeld bekijken: een ontwikkelaar heeft een feature-branch gemaakt van develop, twee commits gedaan, en in de tussentijd hebben andere ontwikkelaars drie commits aan develop toegevoegd. Rebase verplaatst de twee commits van feature naar een nieuwe locatie en maakt kopieën met nieuwe SHA's.

# 1. Feature-branch aanmaken
git checkout -b feature/payment-refactor develop

# 2. Commits doen in feature
git commit -m "refactor: extract payment validation"
git commit -m "refactor: add payment gateway interface"

# 3. Develop bijwerken (werk van collega's)
git checkout develop
git pull

# 4. Feature herbased op nieuwe develop
git checkout feature/payment-refactor
git rebase develop

# 5. Nu kan feature via fast-forward worden gemerged
git checkout develop
git merge feature/payment-refactor

Als er bij stap 4 een conflict optreedt, stopt Git bij de problematische commit. De ontwikkelaar lost het conflict op, voert git add uit en voert git rebase --continue uit. Als een commit moet worden overgeslagen — git rebase --skip, om de hele rebase te annuleren — git rebase --abort.

Automatisch overslaan van lege commits

De vlag --empty regelt het gedrag van rebase bij lege commits — situaties waarin alle wijzigingen van de commit al aanwezig zijn in de doelbranch. Standaard stopt rebase en vraagt om een beslissing. Met de vlag --empty=drop slaat Git dergelijke commits automatisch over zonder te stoppen, wat massaal herbaseren met een groot aantal commits versnelt.

Interactieve Rebase

Interactive rebase (git rebase -i) — een krachtig hulpmiddel voor het bewerken van de commitgeschiedenis. Het opent een editor met een lijst van commits en belangrijke commando's: pick (behouden), reword (bericht wijzigen), edit (inhoud wijzigen), squash (samenvoegen met vorige), fixup (samenvoegen zonder bericht), drop (verwijderen).

# Interactieve rebase van de laatste 4 commits
git rebase -i HEAD~4

# In de editor wordt het rebase-plan geopend:
# pick a1b2c3 feat: add login screen
# pick d4e5f6 fix: login validation
# pick g7h8i9 fix: login layout
# pick j0k1l2 docs: add login comments

# We wijzigen naar:
# pick a1b2c3 feat: add login screen
# squash d4e5f6 fix: login validation
# squash g7h8i9 fix: login layout
# drop j0k1l2 docs: add login comments

Resultaat: drie commits (inlogscherm, validatie, layout) zijn samengevoegd tot één, en de commit met opmerkingen is verwijderd. Dit maakt het mogelijk een schone geschiedenis zonder kladjes en correcties aan te bieden voor code review. Interactive rebase is het standaardinstrument voor het voorbereiden van een feature-branch voor een Pull Request.

Rebase vs Merge: vergelijking

Rebase en Merge lossen dezelfde taak op — het integreren van wijzigingen — maar op fundamenteel verschillende manieren. De keuze tussen beide hangt af van welke geschiedenis je in git log wilt zien en wie er nog meer met jouw branch werkt.

Praktische regel: gebruik merge voor integratie in gemeenschappelijke branches (develop, main) en rebase voor het bijwerken van persoonlijke feature-branches naar de actuele toestand. Veel teams combineren: rebase feature op develop, daarna --no-ff merge in develop.

Invloed op git bisect

Git bisect — een hulpmiddel voor het vinden van de commit die een regressie heeft geïntroduceerd. Bij gebruik van merge doorloopt git bisect correct de merge-commits, rekening houdend met beide ouders. Bij rebase werkt bisect sneller omdat de geschiedenis lineair is en geen vertakking vereist. Als rebase echter is gedaan nadat de commits bij het team bekend waren, gaan de originele SHA's verloren en kan bisect de problematische commit mogelijk niet vinden.

Wanneer Rebase toepassen

Rebase is optimaal in drie scenario's: het voorbereiden van een feature-branch voor Pull Request, het bijwerken van een persoonlijke branch naar de actuele stand van main/develop en het opschonen van de geschiedenis voor het mergen. In elk geval verbetert rebase de leesbaarheid van de geschiedenis zonder risico voor teamwerk.

Voor een Pull Request wordt aanbevolen interactive rebase uit te voeren om werkcommits (WIP, correcties na review) samen te voegen tot betekenisvolle logische eenheden. Dit vergemakkelijkt code review: de reviewer ziet niet 15 kleine commits, maar 3-5 gestructureerde wijzigingen met begrijpelijke berichten.

Voor het bijwerken van een feature-branch heeft rebase de voorkeur boven merge omdat het geen overbodige merge-commits maakt. Als je periodiek git rebase develop binnen de feature-branch doet, zal er na de definitieve merge geen waterval van 10 merge-commits zijn — alleen schone feature-commits bovenop develop.

Geschiedenis opschonen via interactive rebase voor het mergen maakt het mogelijk kleine correcties (typefouten, opmaak) te verbergen en commits te groeperen op functionaliteit. Git-berichten moeten de Conventional Commits-conventie volgen (fix:, feat:, refactor:, docs:), wat een automatische changelog genereert.

Risico's en regels van Rebase

Rebase — een gevaarlijke bewerking als deze verkeerd wordt toegepast. Het grootste risico is het herschrijven van gepubliceerde geschiedenis. Als een ontwikkelaar een branch rebaset die anderen al hebben gepusht en gebruiken, raken hun lokale kopieën gedesynchroniseerd en moeten ze een force-pull doen met risico op gegevensverlies.

• Gouden regel: rebase nooit commits die al bestaan in de gedeelde repository. Dit geldt voor alle branches waartoe andere teamleden toegang hebben
• Force push: na rebase van een lokale feature-branch is push met de vlag --force-with-lease vereist, die veiliger is dan --force omdat wordt gecontroleerd of iemand de branch op de server heeft bijgewerkt
• Contextverlies: rebase vernietigt informatie over wanneer en van welke branch de feature-branch is gemaakt. Als het belangrijk is de aanmaakdatum van de branch te bewaren — gebruik dan merge
• Conflicten: bij rebase moeten conflicten voor elke commit afzonderlijk worden opgelost, wat vermoeiend kan zijn bij een groot aantal commits

Om risico's te minimaliseren, volg de regel: rebase alleen voor persoonlijke branches die niet zijn gepubliceerd. Als de branch al in de gedeelde repository staat — gebruik dan merge met --no-ff. Bij noodzaak tot rebase van een gepubliceerde branch — waarschuw het team en stem force push van tevoren af.

Automatische bescherming tegen gevaarlijke rebase wordt gerealiseerd via server-side hooks: een pre-receive hook aan de serverzijde van Git kan controleren of de push gepubliceerde commits herschrijft. GitHub en GitLab bieden ingebouwde bescherming voor beschermde branches — force push wordt geblokkeerd tenzij de bescherming door een beheerder is opgeheven.