Hva er forskjellen mellom rebase og merge?

Question

Accepted Answer

Både **merge** og **rebase** integrerer endringer fra en gren inn i en annen, men de gjør det på forskjellige måter: merge **bevarer historikk** med en merge-commit, mens rebase **omskriver historikk** for å skape en lineær sekvens. Å forstå forskjellen og når man skal bruke hver metode er viktig.

## Merge — bevarer historikk (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 lineær historikk (gjenskaper)

```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** commitsene dine til å starte fra toppen av en annen gren, og skaper nye commits — som produserer en ren, lineær historikk.

## Den gyldne regel for 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.
```

## Når man skal bruke hver metode

```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 er viktig

Å forstå forskjellen mellom rebase og merge er viktig fordi begge integrerer endringer, men med fundamentalt ulike effekter på historikk, og å velge riktig (og trygt) er viktig, så det er verdifull Git-kunnskap som også blir diskutert regelmessig.

Kjernedistinksjonen — **merge bevarer historikk** (ved å opprette en merge-commit som registrerer at grenene ble kombinert, og bevarer den sanne utviklingshistorikken) mens **rebase omskriver historikk** (ved å gjenskape commits på toppen av en annen grenens tip for å lage en ren, lineær sekvens som om arbeidet var gjort på den nyeste koden) — påvirker hvordan prosjekthistorikken ser ut og leses.

Å forstå avveiningene (merge: nøyaktig men potensielt rotete med merge-commits; rebase: ren og lineær men omskriver commits) hjelper deg å velge basert på om du verdsetter sann historikk eller lineær renhet.

Mest kritisk er det å forstå **den gyldne regel for rebasing** — **aldri rebase commits som er blitt pushet/delt** — fordi rebase omskriver commits (gir dem nye hashes), så rebasing av delt historikk divergerer fra det samarbeidspartnerne har, noe som forårsaker alvorlig forvirring og konflikter; rebase er bare trygt for lokale, ikke-pushete commits.

Denne sikkerheetsregelen er vital og en vanlig kilde til problemer når den blir brutt.

Å forstå **når man skal bruke hver metode** (merge for å integrere delte grener og bevare historikk, ofte teamstandarden for å merge funksjoner via pull requests; rebase for å rydde opp i lokale commits før deling eller holde en funksjonsgran lineært oppdatert — bare på lokale commits) reflekterer god Git-praksis.

Da integrering av endringer er grunnleggende og merge-vs-rebase-valget (med dets historikk- og sikkerhetsimplikasjoner) er en hyppig beslutning og intervjutema, er det å forstå forskjellen — deres effekter på historikk, den kritiske gyldne regel, og når man skal bruke hver metode — verdifull, praktisk-viktig Git-kunnskap som er sentral for å opprettholde ren historikk trygt og en vanlig diskutert distinksjon som alle utviklere bør forstå.