Rebase vs Merge, Explained Properly

In one line

Merge preserves history exactly as it happened; rebase rewrites it into a cleaner, linear story — neither is universally 'correct,' and knowing the actual trade-off matters more than picking a side in the debate.

0/4 · 0%

Think of it like this

Merge is like keeping the actual, messy sequence of events in a shared story ('I wrote this, then you wrote that, then we combined them') — rebase is like rewriting the story afterward as if you'd written your part cleanly AFTER everything that came before, even though that's not literally what happened chronologically.

Key ideas

01
git merge combines two branches by creating a new MERGE COMMIT with two parents (Phase 0.5) — the original history of both branches is preserved exactly as it happened, including every commit, in its original order, with the branching and joining points clearly visible in the graph.
02
git rebase <branch> takes your current branch's commits and REPLAYS them, one by one, as if they'd been written starting from the tip of the target branch instead of wherever they originally branched off — the result is a straight, linear history with no merge commits at all, but every replayed commit gets a genuinely NEW SHA, since its parent has changed.
03
This is the single most important fact about rebase: it REWRITES commits, giving them new SHAs. This is exactly why the golden rule from Topic 1.3 applies here too — never rebase commits that have already been pushed and shared, since it changes their identity and creates painful divergence for anyone who already has the old versions.
04
A common, genuinely safe real workflow: rebase your OWN local feature branch onto the latest main before opening a pull request (git rebase main, while still on your feature branch, before anyone else has seen those commits) — this gives you a clean, linear history for review, with zero risk since nobody else has based work on your feature branch's commits yet.
05
Neither approach is objectively correct — merge preserves true history and is always safe on shared branches; rebase produces a cleaner, easier-to-read history but must only be used on commits that are still entirely yours and unshared. Many real teams use both deliberately: rebase locally to clean up before sharing, merge (often via a 'squash merge,' Phase 4) when actually combining into the shared main line.

Code & diagrams

MergeVsRebasediagram

Same two branches, two different ways to bring them together.

Rendering diagram…

rebase-vs-merge.shmarkdown

Compare the resulting history graphs directly.

cd ~/scratch/my-first-repo

# Set up a feature branch that's diverged from main
git switch -c feature/x main
echo "feature work" >> feature.txt
git add feature.txt && git commit -m "Add feature work"

# Meanwhile, main moved forward too
git switch main
echo "unrelated main work" >> main-notes.txt
git add main-notes.txt && git commit -m "Unrelated main work"

# --- Option A: merge feature into main ---
git switch main
git merge feature/x --no-ff
git log --graph --oneline
# shows a merge commit with two parents, full branching history visible

# --- Option B (on a copy, to compare): rebase feature onto main first ---
# git switch feature/x
# git rebase main
# git log --graph --oneline
# shows a straight line — feature's commit now sits AFTER main's, with a new SHA

Explain it without notes

Why does rebasing give a commit a brand new SHA, even if the actual code change is identical to before?

You're about to rebase a branch. What's the one question you must answer 'no' to before it's safe to do?

Practice

Set up two branches that diverge from a common point, merge one into the other with --no-ff, and use git log --graph --oneline to see the resulting two-parent merge commit clearly.

On a separate copy of the same setup, rebase the feature branch onto main instead, and compare the resulting git log --graph --oneline — confirm the feature commit's SHA is different from its original.

Trade-offs

↔
This is the actual trade-off, stated plainly: merge is always safe (never rewrites anything) but produces a busier-looking history with merge commits scattered throughout; rebase produces a clean, linear, easy-to-follow history but is only safe on commits nobody else has seen yet. Teams that value a clean git log above all else lean on rebase-before-sharing habits; teams that value an exact, tamper-proof record of what really happened lean on merge — reasonable, working teams exist on both sides of this.

Done when you can

I can explain what actually happens to commits during a rebase, in terms of SHAs.
I know the golden rule: never rebase commits that have already been shared with others.
I understand merge and rebase are different trade-offs, not a right-answer-vs-wrong-answer debate.