Lesson 8 of 30

Rebasing

Q: What does git rebase actually do at the commit level, how is that different from a merge, and why does the advice 'never rebase a shared branch' exist?

A strong answer covers: Rebase replays commits onto a new base one at a time, producing brand-new commit objects with new hashes — it does not move or edit existing commits; Contrast with merge: merge creates one new commit with two parents and preserves both original histories; rebase produces a linear history and discards the originals; The 'never rebase shared history' rule is about hash identity — collaborators who already have the old commits diverge from the rewritten ones, forcing a force-push and manual reconciliation; Rebase is safe on a local/private branch nobody else has pulled yet.

Rebase doesn't move commits — it replays them. Same changes, brand-new commits, on top of a different base. Powerful for local cleanup, dangerous the moment someone else has pulled the commits you're rewriting.

16 min read

Check your understanding

Every option explains itself — why the right one is right, and why each wrong one is wrong. Miss one and it comes back later on a spaced-repetition schedule.

No quiz for this one — it's a practical topic

This topic is about judgment and practical tradeoffs more than a single right answer — a mock interview is the better way to test yourself on it.

Be interviewed on this →

Stuck? Ask the AI tutor

Hints without spoilers, and a plain explanation of why a wrong answer was wrong — answered only from this lesson. Free account, no card.

Interview questions on Rebasing

What interviewers actually ask about this, and what a strong answer has to cover.

What does git rebase actually do at the commit level, how is that different from a merge, and why does the advice 'never rebase a shared branch' exist?

A strong answer covers

Rebase replays commits onto a new base one at a time, producing brand-new commit objects with new hashes — it does not move or edit existing commits
Contrast with merge: merge creates one new commit with two parents and preserves both original histories; rebase produces a linear history and discards the originals
The 'never rebase shared history' rule is about hash identity — collaborators who already have the old commits diverge from the rewritten ones, forcing a force-push and manual reconciliation
Rebase is safe on a local/private branch nobody else has pulled yet

Likely follow-ups

If a commit's hash is derived from its content and parent, why can't rebase just relabel the old commit with a new parent instead of creating a whole new object?
What actually happens on the collaborator's machine if they've already built commits on top of the branch you force-pushed after rebasing?
Walk me through what a multi-commit rebase conflict looks like in practice — does it resolve all at once like a merge conflict does?

The plain-language idea

git merge combines two histories by creating a new commit that has both branches as parents — the diamond shape from the previous lesson. git rebase takes a completely different approach: it replays your branch's commits, one at a time, on top of a different starting point, as if you'd written them there in the first place.

The critical detail people miss: rebase doesn't move your existing commits — it can't, because a commit's hash is derived from its content plus its parent. Change the parent, and you get a different hash, which means a different commit object entirely. So git rebase main while on feature takes each commit unique to feature, computes the same diff, and creates a brand-new commit with that diff applied on top of main's current tip. The old commits still exist in the object store for a while (reflog can find them), but your branch pointer now refers to the new ones. The result looks like you built your feature on top of the latest main all along — history reads as a straight line, no diamond.

This is exactly why the "never rebase a shared/public branch" rule exists. If anyone else has already pulled your original commits and built on top of them, rebasing rewrites those commits into new ones with new hashes. Your collaborators' history and your rewritten history now disagree about what the "real" commits are — pushing your rebase forces a --force push, and everyone who already has the old commits has to manually reconcile a history that no longer matches. Rebase is safe and genuinely useful on a branch only you're working on, before anyone else has fetched it.

See it in a real thing: replaying commits onto a moved base

$ git log --oneline --graph --all
* c3d4e5f (feature) tweak login copy
| * b2c3d4e (main) fix header typo
|/
* a1b2c3d initial commit

$ git switch feature
$ git rebase main
Successfully rebased and updated refs/heads/feature.

$ git log --oneline --graph --all
* d4e5f6a (HEAD -> feature) tweak login copy
* b2c3d4e (main) fix header typo
* a1b2c3d initial commit

Notice c3d4e5f is gone from the log, replaced by d4e5f6a — same content, same message, different hash, different parent. That's a genuinely new commit object, not the old one relocated. History is now a straight line: main's fix, then feature's tweak, as if feature had been branched after the header fix instead of before it.

Merge vs. rebase: same commits, different shapeStep 1 of 4

Both sides start identical: main has commits A, B, C. feature branched off B and has its own commits D, E.

What people usually miss

Watch out

A rebased commit is a different object, even with identical content. git rebase doesn't relabel c3d4e5f as living somewhere new — it creates d4e5f6a and abandons c3d4e5f. Anyone still holding a reference to the old hash is now looking at a commit your branch no longer includes.
"Never rebase shared history" is about hash identity, not etiquette. It's not a stylistic preference — rewriting shared commits creates two divergent, hash-incompatible histories that Git has no automatic way to reconcile, forcing a disruptive force-push and manual cleanup for every collaborator.
Rebase can produce merge conflicts too, and they resolve differently than a merge conflict. Since commits replay one at a time, you can hit a conflict on commit 3 of 5, resolve it, git rebase --continue, and hit another on commit 4 — it's iterative, not a single conflict resolution like git merge gives you.

The genealogy: same object model, different operation

Rebase only makes sense once you know commits are immutable, hash-derived objects, not editable records — that's the whole reason "rewriting" a commit actually means creating a new one and discarding the old. It's the identical content-addressable model from the mental-model lesson, just applied to explain why rebase can't quietly mutate history in place the way a text editor mutates a file.