Rebase vs Merge: What's the Difference?

Ask a room of developers whether to merge or rebase and you'll start an argument. That's unfortunate, because the underlying ideas are not controversial at all — they're two different, sensible answers to the same question: how should I combine my work with everyone else's? This chapter explains what rebase actually does, how it differs from the merge you already understand, and the one rule that keeps it from causing trouble. No tribalism, just the mechanics and the trade-off.

The same problem, two solutions

Here's the everyday situation. You branched off main to build a feature. While you worked, main moved on — teammates pushed new commits. Now your branch and main have diverged, and you want your feature to sit on top of the latest main. You have two ways to get there.

• Merge — pull main's new commits into your branch with a merge commit, joining the two lines. You already know this one.
• Rebase — move your commits so they sit on top of the latest main, as if you'd branched from there in the first place.

Both end with your work combined with the latest main. The difference is entirely in the shape of the history they leave behind.

What rebase actually does

The word "rebase" is literal: it changes the base your commits are built on. Right now your feature commits are based on an old version of main. Rebasing sets a new base — the latest main — and re-applies your commits there, one by one.

The result is a straight line: latest main, then your commits neatly stacked on top, with no fork and no merge commit. It looks as though you started your work after all of main's recent commits — even though, in reality, you didn't. That tidiness is the whole appeal of rebasing.

The crucial difference: rebase rewrites

Here's the part that matters most, and it connects straight back to how Git stores history. Recall that a commit's ID is a hash of its contents including its parent. When rebase replays your commits onto a new base, their parent changes — so every replayed commit gets a brand-new hash. They are, technically, new commits. The originals are discarded and replaced.

Merge does not do this. A merge leaves all existing commits exactly as they were and simply adds one new merge commit on top. Nothing is rewritten; the true, forked shape of what happened is preserved forever.

So the trade-off comes into focus. Merge is honest — it records that two lines diverged and rejoined, merge commits and all. Rebase is tidy — it rewrites your work into a clean line that's easy to read, at the cost of showing history as it never quite happened. Neither is wrong. Teams that value a readable, linear log lean on rebase; teams that value an exact record lean on merge. Many use both: rebase to tidy their own branch, merge to bring it into main.

The golden rule

There is exactly one hard rule, and breaking it is the source of nearly every rebase horror story:

Never rebase commits that other people already have.

The reasoning follows directly from "rebase rewrites." If you rebase commits you've already pushed and a teammate has already pulled, you've now replaced those commits with new ones that have different IDs. Their copy still has the old commits. When your two histories meet, Git sees two sets of commits that look different but represent the same work, and everything tangles — duplicated commits, confusing conflicts, and a genuine mess to untangle.

So the safe boundary is simple: rebase freely on commits that are still private to you (your local, unpushed work — tidy it all you like), and never rebase commits that have left your machine and might be in someone else's repository. Private history is yours to reshape; shared history is not.

Choosing, without the drama

Put it together and the choice is calm, not ideological. Use merge when you want an accurate record of how work actually came together, and always when combining shared branches. Use rebase to clean up your own not-yet-shared commits into a tidy line before you share them — updating a private feature branch onto the latest main, or squashing messy work-in-progress commits into something readable. Respect the golden rule and rebase is a safe, powerful tool; ignore it and it bites. Either way, you now understand both well enough to reason for yourself instead of picking a side. The next chapter tackles the other thing everyone fears they've done permanently — a mistake — and shows how Git lets you undo almost anything.