Vad är skillnaden mellan rebase och merge?

Question

Accepted Answer

Både **merge** och **rebase** integrerar ändringar från en gren till en annan, men de gör det på olika sätt: merge **bevarar historiken** med en merge-commit, medan rebase **skriver om historiken** för att skapa en linjär sekvens. Att förstå skillnaden och när man ska använda var och en är viktigt.

## Merge — bevarar historiken (kombinerar)

```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 — skriver om för en linjär historik (spelar upp igen)

```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 **flyttar** din grens commits för att börja från spetsen av en annan gren, vilket skapar nya commits — och producerar en ren, linjär historik.

## Rebasing gyllene regel

```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 ska använda var och en

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

## Varför det spelar roll

Att förstå skillnaden mellan rebase och merge är viktigt eftersom båda integrerar ändringar men med fundamentalt olika effekter på historiken, och att välja rätt (och säkert) spelar roll, så det är värdefull Git-kunskap som också diskuteras ofta.

Kärnskillnaden — **merge bevarar historiken** (skapande en merge-commit som registrerar grenarna kombinerade, vilket bevarar den sanna utvecklingshistoriken) medan **rebase skriver om historiken** (spelar upp commits på spetsen av en annan grens för att skapa en ren, linjär sekvens som om arbetet hade gjorts på den senaste koden) — påverkar hur projekthistoriken ser ut och läses.

Att förstå kompromisserna (merge: korrekt men potentiellt rörig med merge-commits; rebase: ren och linjär men skriver om commits) hjälper till att välja baserat på om man värderar sann historik eller linjär renhet.

Mest kritiskt är det att förstå **rebasing gyllene regel** — **aldrig rebase commits som har pushats/delats** — eftersom rebase skriver om commits (ger dem nya hasher), så rebasing av delad historik avviker från vad medarbetare har, vilket orsakar allvarlig förvirring och konflikter; rebase är säkert endast för lokala, opushade commits.

Denna säkerhetregel är vital och en vanlig källa till problem när den brytes.

Att förstå **när man ska använda var och en** (merge för att integrera delade grenar och bevara historiken, ofta teamets standard för att slå samman features via pull requests; rebase för att rensa upp lokala commits innan delning eller hålla en feature-gren linjärt uppdaterad — endast på lokala commits) återspeglar sund Git-praxis.

Since integrating changes is fundamental and the merge-vs-rebase choice (with its history and safety implications) is a frequent decision and interview topic, understanding the difference — their effects on history, the critical golden rule, and when to use each — is valuable, practically-important Git knowledge that's central to maintaining clean history safely and a commonly-discussed distinction every developer should grasp.