Git Rebase vs Merge: When to Use Which

Few Git questions generate more heated opinions than “rebase or merge?” The honest answer is that both are correct tools for different jobs, and understanding what each actually does to your history removes most of the mystery.

Merge: Preserves True History

git checkout main
git merge feature-branch
# Creates a new merge commit joining both histories,
# preserving exactly how development actually happened

A merge commit has two parents and tells the true story: these two lines of development happened in parallel and were joined at this point. Nothing about existing commits is rewritten, which makes merge the only safe option for any branch other people have already pulled.

Rebase: Rewrites History for Linearity

git checkout feature-branch
git rebase main
# Replays your feature branch's commits one by one on top of
# main's current tip, producing a straight, linear history

Rebase produces a cleaner, linear commit log with no merge commits cluttering the graph, but it does this by creating entirely new commits with new hashes — the original commits are discarded. This is why the golden rule exists:

The One Rule That Matters

Never rebase a branch that others have already pulled from. Rewriting shared history means everyone else’s local branch now diverges from the “real” history, leading to painful, confusing merge conflicts when they try to sync up.

A Practical Default

• Rebase your own local feature branch to clean it up before opening a pull request — nobody else has seen those commits yet.
• Merge (or squash-merge) when integrating a finished feature branch into main — preserve the fact that it happened, without needing a perfectly linear log for a completed piece of work.
• Use git pull --rebase instead of a regular pull to avoid pointless “merge remote-tracking branch” noise commits on your own branch.