Git Rebase vs Merge, Actually Explained

TL;DR: Rebase rewrites history. Merge preserves it. The choice depends on what you want your log to look like in two years.

The short version

Rebase rewrites history. Merge preserves it. The choice depends on what you want your log to look like in two years.

This guide covers the mental model, the patterns that pay off, and the trade-offs that decide whether a technique fits your code.

Working example

Here's a minimal example you can run as-is. Drop it in a fresh file, run it, and trace through it once before reading the rest.

# Create + push a feature branch
git switch -c feat/new-thing
# ... edit files ...
git add -A
git commit -m "feat: new thing"
git push -u origin feat/new-thing

Why this pattern

The shape above shows up in real Git codebases because it satisfies three constraints at once: it stays type-safe, it composes with the rest of the language's idioms, and it leaves a clear trail for the next developer (which, in six months, is you).

When you write the same pattern three times in a project, extract it. When you write it three times across projects, extract it into a shared library.

A common variant

The same idea adapted for a different shape. Notice how the structure stays the same — only the specifics change.

git fetch origin
git rebase origin/main
# resolve any conflicts, then:
git rebase --continue
git push --force-with-lease

Trade-offs to watch

Every pattern has a failure mode. The most common one here is over-application: developers who learn a technique apply it everywhere, including places where simpler code would have been clearer.

Rule of thumb: if the abstraction takes more lines to describe than it saves, the abstraction is wrong.

A more involved example

Once the basic pattern is clear, here's how it composes with surrounding code. Read this one slowly.

git bisect start
git bisect bad           # current HEAD is broken
git bisect good v1.4.0   # this tag worked
# git checks out a midpoint; you test:
make test && git bisect good || git bisect bad
# repeat until git names the bad commit
git bisect reset

When to skip it

If the surrounding code is already simple, don't reach for Git-specific cleverness. Boring code is a feature. Save the patterns for places where they actually pay off — usually at module boundaries, in shared libraries, or where the alternative would be 50 lines of repetition.

FAQ

Related reading

• git reflog: The Command That Saves Your Work
• Git Bisect: Real Debugging With Binary Search
• Interactive Rebase: A Deep Dive
• The TypeScript satisfies Operator in Practice
• Poetry vs Pipenv vs uv: The 2026 Take