Hvad er forskellen mellem rebase og merge?

Question

Accepted Answer

Både **merge** og **rebase** integrerer ændringer fra én gren til en anden, men de gør det forskelligt: merge **bevarer historikken** med en merge commit, mens rebase **omskriver historikken** for at skabe en lineær sekvens. Det er vigtigt at forstå forskellen og hvornår man skal bruge hver enkelt.

## Merge — bevarer historikken (kombinerer)

```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 — omskriver for en lineær historik (gentager)

```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 **flytter** dine branches commits til at starte fra toppen af en anden gren, hvilket skaber nye commits — og producerer en ren, lineær historik.

## Rebase-reglen

```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.
```

## Hvornår skal man bruge hver enkelt

```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.
```

## Hvorfor det betyder noget

At forstå forskellen mellem rebase og merge er vigtig, fordi begge integrerer ændringer, men med fundamentalt forskellige virkninger på historikken, og det at vælge korrekt (og sikkert) betyder noget, så det er værdifuld Git-viden, der også diskuteres almindeligt.

Den centrale distinktion — **merge bevarer historikken** (opretter en merge commit, der registrerer grenene kombineret, og bevarer den sande udviklinghistorik) mens **rebase omskriver historikken** (gentager commits på toppen af en anden branches tip for at skabe en ren, lineær sekvens, som om arbejdet var udført på den seneste kode) — påvirker, hvordan projekthistorikken ser ud og læses.

At forstå afvejningerne (merge: nøjagtig, men potentielt uorden med merge commits; rebase: ren og lineær, men omskriver commits) hjælper med at vælge baseret på, om du værdsætter sand historik eller lineær renhed.

Mest kritisk er det at forstå **rebase-reglen** — **aldrig rebase commits, der er blevet pushed/delt** — væsentligt, fordi rebase omskriver commits (giver dem nye hashes), så rebasing delt historik divergerer fra, hvad samarbejdspartnere har, hvilket forårsager alvorlig forvirring og konflikter; rebase er kun sikkert for lokale, ikke-pushede commits.

Denne sikkerhedsregel er afgørende og en hyppig kilde til problemer, når den overtrædes.

At forstå **hvornår man skal bruge hver enkelt** (merge til at integrere delte grene og bevare historikken, ofte teamstandarden for at merge features via pull requests; rebase til at rense lokale commits, før man deler, eller til at holde en feature branch lineært up-to-date — kun på lokale commits) afspejler sund Git-praksis.

Da integrering af ændringer er grundlæggende, og merge-versus-rebase valget (med dets historik- og sikkerhedsimplikationer) er en hyppig beslutning og interviewemne, er det at forstå forskellen — deres virkninger på historikken, den kritiske regel, og hvornår man skal bruge hver enkelt — værdifuld, praktisk vigtig Git-viden, der er central for at opretholde ren historik sikkert og en almindeligt diskuteret distinktion, som enhver udvikler bør forstå.