What is the difference between rebase and merge?

Question

Accepted Answer

Both **merge** and **rebase** integrate changes from one branch into another, but they do it differently: merge **preserves history** with a merge commit, while rebase **rewrites history** to create a linear sequence. Understanding the difference and when to use each is important.

## Merge — preserves history (combines)

```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 — rewrites for a linear history (replays)

```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 **moves** your branch's commits to start from the tip of another branch, creating new commits — producing a clean, linear history.

## The golden rule of 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.
```

## When to use each

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

## Why it matters

Understanding the difference between rebase and merge is important because both integrate changes but with fundamentally different effects on history, and choosing correctly (and safely) matters, so it's valuable Git knowledge that's also commonly discussed.

The core distinction — **merge preserves history** (creating a merge commit that records the branches combined, keeping the true development history) while **rebase rewrites history** (replaying commits onto another branch's tip to create a clean, linear sequence as if the work had been done on the latest code) — affects what the project history looks like and reads like.

Understanding the trade-offs (merge: accurate but potentially cluttered with merge commits; rebase: clean and linear but rewriting commits) helps choose based on whether you value true history or linear cleanliness.

Most critically, understanding the **golden rule of rebasing** — **never rebase commits that have been pushed/shared** — is essential because rebasing rewrites commits (giving them new hashes), so rebasing shared history diverges from what collaborators have, causing serious confusion and conflicts; rebase is safe only for local, unpushed commits.

This safety rule is vital and a common source of problems when violated.

Understanding **when to use each** (merge for integrating shared branches and preserving history, often the team default for merging features via pull requests; rebase for cleaning up local commits before sharing or keeping a feature branch linearly up-to-date — on local commits only) reflects sound Git practice.

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.