Why Rebase

Updated

October 30, 2026

Why Rebase? Clean History vs Merge Commits

After this page you can say what rebase copies, and why the hashes change.

Replay commits on a new parent

You branched from main at C. main moved to G. Rebase copies your commits D and E as D' and E' with parent G:

A ← B ← C ← G                main
          ← D ← E            feat/ping-json

# git switch feat/ping-json && git rebase main

A ← B ← C ← G                main
              ← D' ← E'      feat/ping-json

D' has a new hash. The patch is similar; the parent is G. Git then fast-forwards or you --ff-only merge into main.

cd ~/desk/desk-api
git switch feat/ping-json
git rebase main

What you gain

  • main can stay a single chain (fast-forward).
  • Reviewers read your commits on top of current main, not an old base.
  • git log --first-parent on main after --ff-only is your feature commits, not a merge node.

What you pay

  • New hashes. Anyone who fetched D and E now has stale names.
  • Conflicts are replayed per copied commit, not once in a merge commit.

Rebase unpublished work (your feature branch). Merge published history you share (main that others pulled). Chapter 11 is force-push if you already pushed the old D and E.

rebase vs merge in one line

Merge adds a join. Rebase copies a chain onto a new base. Both produce a tree that contains both sides of the work. The graph looks different. The next pages are interactive rebase, conflicts, pull --rebase, and when to pick which.