Few Git topics start more arguments than Git rebase vs merge. Both integrate changes from one branch into another, both get you to the same final code, and yet developers hold near-religious opinions about which to use. The good news: once you understand what each actually does to your history, the “right” answer for a given situation is usually obvious.
What merge does
A merge takes the changes from your branch and ties them into the target with a new merge commit. Your branch’s history stays exactly as it happened:
git checkout main
git merge featureThe result is a history that shows the true story — this branch existed, work happened on it, and here is where it rejoined. You get an explicit record of when and how the integration occurred. The cost is a busier graph with lots of merge commits.
Merge keeps the branch visible: the two feature commits stay put, and a new merge commit ties them back into main.
What rebase does
A rebase instead replays your branch’s commits on top of the latest target, as if you had started your work from there:
git checkout feature
git rebase mainThe result is a clean, linear history with no merge commits — it looks like everything happened in a tidy sequence. The catch is that rebasing rewrites commit hashes, creating new commits in place of the old ones.
Rebase replays the same two feature commits (now A′ and B′ — new hashes) in a straight line on top of main. No merge commit, no branch in the graph.
The golden rule
Here is the one rule that prevents disasters: never rebase commits you have already pushed and shared. Because rebase rewrites history, rebasing a branch other people are working on forces them into a painful mess of duplicated commits. Rebase your local, unpushed work freely; leave shared history alone.
Git rebase vs merge: at a glance
Before the workflow, here is the whole trade-off on one screen:
| Dimension | Merge | Rebase |
|---|---|---|
| History shape | Branching graph + a merge commit | Straight, linear line |
| Commit hashes | Preserved (unchanged) | Rewritten — new commits replace the old |
| When integration happened | Explicitly recorded in the merge commit | Not shown — looks like one sequence |
| Conflicts | All at once, in a single step | Commit-by-commit as each is replayed |
| Safe on shared branches? | Yes | No — never rebase pushed history |
| Use when | Integrating a reviewed branch into main |
Tidying your own local work before you push |
A workflow that uses both
The teams I have enjoyed working on do not pick a side — they use each where it shines. Rebase your feature branch onto the latest main before opening a pull request (where your CI pipeline runs), so your changes apply cleanly and your commits read as a coherent story. Then merge the reviewed branch into main, so there is a clear, permanent record of when the feature landed.
Interactive rebase: the feature that changes how you commit
Plain rebase moves commits; interactive rebase (git rebase -i) lets you edit them — and once you learn it, it changes how you work. Running git rebase -i main on your feature branch opens a list of your commits with an action per line:
pick a1b2c3 Add password reset endpoint
squash d4e5f6 fix typo
squash g7h8i9 fix the fix
reword j0k1l2 WIP more reset stuffThose three embarrassing fix-the-fix commits collapse (squash) into their parent; the vague “WIP” message gets rewritten (reword) into something meaningful; you can also reorder commits or drop dead ends entirely. The liberating consequence: you can commit constantly and messily while working — checkpoint every twenty minutes, commit before risky experiments — because interactive rebase lets you rewrite that scratchwork into a clean, reviewable story before anyone sees it. Commit early and often for yourself; curate the history for your reviewers. The golden rule still applies: do this before pushing, not after — and while you’re cleaning up those commits, it’s the perfect moment to make sure no credentials slipped in, part of keeping secrets out of Git.
When conflicts strike: the practical difference
Both operations can hit conflicts, but they hit differently, and this shapes real preferences. A merge presents all conflicts at once, in one commit — one painful session, resolved and done. A rebase replays commits one at a time, so conflicts arrive commit-by-commit: smaller and more understandable individually, but you may resolve related conflicts repeatedly across several commits of a long branch. A good merge tool takes the sting out of either — most editors ship one, as covered in these VS Code tips.
Two safety valves everyone should know before their first hairy rebase: git rebase --abort instantly returns you to the pre-rebase state, no harm done — there’s no shame in bailing out of a conflict swamp and merging instead. And if a rebase (or any history surgery) goes wrong after completing, git reflog shows every position your branch has occupied, letting you reset back to before the damage. Rebase feels dangerous mainly to people who don’t know the escape hatches exist.
What “squash and merge” on GitHub actually is
Modern platforms quietly added a third option to this debate. GitHub’s “Squash and merge” button collapses your entire pull request into a single commit on main — effectively rebase’s cleanliness applied wholesale, without you running rebase at all. Its sibling “Rebase and merge” replays your commits individually onto main with no merge commit.
Many teams now standardize on squash-merge and sidestep the debate entirely: main becomes a tidy sequence of one-commit-per-PR, messy branch history evaporates at merge time, and nobody argues about local workflow. The trade-off is losing the individual commits’ detail — fine when PRs are small and focused, painful when someone lands a 40-file PR as one opaque commit. If your team squash-merges, the practical advice inverts: don’t fuss over branch commit hygiene, but keep PRs small, because each becomes exactly one unit of history and one unit of revert.
Command cheat sheet
The commands that come up across every rebase-vs-merge workflow, in one place:
| Command | What it’s for |
|---|---|
git merge <branch> |
Integrate a branch, creating a merge commit |
git rebase <branch> |
Replay your commits on top of another branch (linear history) |
git rebase -i <base> |
Interactively squash, reword, reorder, or drop commits |
git rebase --abort |
Bail out of an in-progress rebase, no harm done |
git reflog |
See every position HEAD has held; recover from a bad rewrite |
git push --force-with-lease |
Safely force-push a rebased branch (refuses if the remote moved) |
git pull --rebase |
Update by rebasing local commits instead of adding a merge commit |
Frequently asked questions
When should I use git rebase vs merge? Use rebase to tidy your own local, unpushed commits before sharing them — it gives a clean, linear history. Use merge to integrate a reviewed branch into main, where the merge commit is a useful record of when the feature landed. Never rebase commits others already have.
I rebased a pushed branch by accident — now what? If it’s your personal branch and nobody has pulled it, force-push with git push --force-with-lease (safer than plain --force: it refuses if someone else pushed meanwhile). If teammates already have the old history, coordinate before force-pushing — that’s exactly the mess the golden rule exists to prevent.
What is git pull --rebase and should I use it? It rebases your local commits on top of the fetched remote instead of creating a merge commit every time you pull. Most developers prefer it (many set it as default: git config --global pull.rebase true) — it eliminates those noisy “Merge branch ‘main’ of…” commits from routine syncing. Your unpushed local commits are exactly the safe case for rebasing.
Does rebase lose my work if it goes wrong? Practically no — completed states are recoverable via reflog for weeks, and --abort exits cleanly mid-operation. The realistic risk isn’t lost code; it’s inflicted confusion on collaborators when shared history gets rewritten.
What’s the difference between “squash and merge” and “rebase and merge” on GitHub? Squash and merge collapses your entire pull request into a single commit on main — tidy, but you lose the individual commits. Rebase and merge replays each of your commits individually onto main with no merge commit — a linear history that keeps every commit. A plain merge, by contrast, adds a merge commit and preserves the branch shape.
The bottom line
Merge preserves history exactly as it happened; rebase rewrites it to be linear and clean. Use rebase to tidy your own work before sharing it, use merge to integrate shared branches, and never rebase what others depend on. Frame Git rebase vs merge that way and the endless debate turns into a simple, situational choice.
