Wat is het verschil tussen rebase en merge?

Question

Accepted Answer

Zowel **merge** als **rebase** integreren veranderingen van de ene branch in een andere, maar ze doen het op verschillende manieren: merge **bewaart de geschiedenis** met een merge commit, terwijl rebase **de geschiedenis herschrijft** om een lineaire volgorde te creëren. Het is belangrijk om het verschil te begrijpen en te weten wanneer je elk moet gebruiken.

## Merge — bewaart de geschiedenis (combineert)

```text
main:     A───B───C───────M     ← M is a MERGE COMMIT (two parents)
                  \       /
feature:           D───E
→ git merge feature: creates M combining the branches
  ✓ Preserves the actual history (shows the branch existed, when it merged)
  ✗ History has merge commits (can look cluttered with many merges)
```

## Rebase — herschrijft voor een lineaire geschiedenis (speelt opnieuw af)

```text
BEFORE:  main: A───B───C    feature: A───B───D───E
AFTER rebase feature onto main:
         main: A───B───C    feature: A───B───C───D'───E'
→ git rebase main (on feature): REPLAYS feature's commits (D,E) ON TOP of main's latest (C)
  ✓ LINEAR, clean history (no merge commits) — as if feature was built on current main
  ✗ REWRITES commits (D→D', E→E' are NEW commits with new hashes)
```

Rebase **verplaatst** de commits van je branch zodat ze starten vanaf de tip van een andere branch, waardoor nieuwe commits ontstaan — wat resulteert in een schone, lineaire geschiedenis.

## De gouden regel van rebasing

```text
⚠️ NEVER rebase commits that have been PUSHED/SHARED (public history):
  → rebasing rewrites commits (new hashes) → diverges from what others have
  → causes serious confusion and conflicts for collaborators
→ Rebase only LOCAL, unpushed commits. Merge for integrating shared/public branches.
```

## Wanneer elk te gebruiken

```text
MERGE  → integrating shared branches; preserving true history; team default for merging
  features to main (often via pull requests). Safe, non-destructive.
REBASE → cleaning up LOCAL commits before sharing; keeping a feature branch up-to-date
  with main (linear); achieving clean linear history. On local/private commits only.
→ Common workflow: rebase locally to tidy up, then merge (or PR) into main.
```

## Waarom het belangrijk is

Het begrijpen van het verschil tussen rebase en merge is belangrijk omdat beide veranderingen integreren, maar met fundamenteel verschillende gevolgen voor de geschiedenis. Het correct (en veilig) kiezen is belangrijk, dus het is waardevol Git-kennis dat ook veel besproken wordt.

Het kernverschil — **merge bewaart de geschiedenis** (door een merge commit te creëren die opnieuw aangeeft dat branches zijn gecombineerd, wat de ware ontwikkelings-geschiedenis behoudt) terwijl **rebase de geschiedenis herschrijft** (commits opnieuw afspeelt op de tip van een andere branch om een schone, lineaire volgorde te creëren alsof het werk was gedaan op de nieuwste code) — bepaalt hoe de projectgeschiedenis eruit ziet en leest.

Het begrijpen van de afwegingen (merge: nauwkeurig maar mogelijk rommelig met merge commits; rebase: schoon en lineair maar commits herschrijven) helpt om te kiezen op basis van of je waarde hecht aan ware geschiedenis of lineaire schoonheid.

Most critically, understanding the **gouden regel van rebasing** — **rebase nooit commits die zijn gepushed/gedeeld** — is essentieel omdat rebasing commits herschrijft (ze nieuwe hashes geeft), dus rebasing van gedeelde geschiedenis divergeert van wat medewerkers hebben, wat ernstige verwarring en conflicten veroorzaakt; rebase is veilig alleen voor lokale, niet-gepushte commits.

Deze veiligheidsregel is van cruciaal belang en is een veelvoorkomende bron van problemen wanneer deze wordt geschonden.

Het begrijpen van **wanneer elk te gebruiken** (merge voor integratie van gedeelde branches en het behouden van geschiedenis, vaak de teamstandaard voor het samenvoegen van functies via pull requests; rebase voor het opschonen van lokale commits voordat je ze deelt of voor het lineair up-to-date houden van een feature branch — alleen op lokale commits) weerspiegelt gezonde Git-praktijk.

Omdat het integreren van veranderingen fundamenteel is en de merge-versus-rebase-keuze (met de gevolgen voor geschiedenis en veiligheid) een veelgestelde beslissing is en een veel besproken interviewonderwerp, is het begrijpen van het verschil — hun effecten op de geschiedenis, de kritieke gouden regel, en wanneer elk te gebruiken — waardevol, praktisch-belangrijk Git-kennis dat centraal staat voor het veilig onderhouden van een schone geschiedenis en een veel besproken onderscheid dat elke ontwikkelaar zou moeten begrijpen.