Side by side
MergevsRebase
What is the difference between git merge and git rebase?
Updated 2 min read7 differences
In short
Git merge joins two branches with a merge commit that keeps the full history, while git rebase replays your commits onto another branch for a linear history.
Merge
A merge in Git combines the changes from one branch into another, joining separate lines of development back together into a single, shared history.
Read the page on MergeRebase
A rebase in Git replays a branch's commits on top of another commit, rewriting history to produce a cleaner, linear sequence of changes without merge commits.
Read the page on RebaseMerge and Rebase compared
| Aspect | Merge | Rebase |
|---|---|---|
| What it does | Joins two branches with a new merge commit | Replays your commits on top of another branch |
| History shape | Branching history showing where work split and joined | One straight, linear history |
| Existing commits | Left unchanged | Rewritten with new commit IDs |
| Conflicts | Resolved once, in the merge commit | May be resolved once per replayed commit |
| Safe on shared branches | Yes, it never rewrites history | No, others keep outdated copies of the commits |
| Pushing afterward | A normal git push works | Needs git push --force-with-lease if already pushed |
| Best for | Integrating finished work into shared branches | Updating a private feature branch and tidying commits |
The difference, explained
git merge and git rebase both bring changes from one branch into another. Merge ties the two histories together with a new merge commit that has two parents. Rebase takes the commits that exist only on your branch, replays them one by one on top of the target branch and creates new copies of them with new commit IDs.
The difference is what happens to history. Merge is non-destructive: existing commits never change, so you can always see when a branch split off and came back, but the log can fill up with merge commits. Rebase gives a straight, linear history that is easier to read and search, but it rewrites commits, which causes trouble for anyone who already has the old ones.
Many teams use both: developers rebase their own feature branch onto the latest main to stay current and tidy, then merge it through a pull request. The golden rule is to never rebase commits that other people have already pulled, such as those on a shared main branch.
A common misconception is that rebasing avoids merge conflicts. Conflicts happen either way when the same lines changed; with rebase, you may even resolve them once for each replayed commit instead of once for the whole merge.
Which one should you use?
Choose Merge when…
- The branch is shared with other developers.
- You want a true record of when work split off and was merged.
- You prefer to resolve all conflicts in one step.
Choose Rebase when…
- You are updating your own feature branch with the latest
main. - You want a clean, linear history that is easy to read.
- You want to tidy up commits before opening a pull request.
Updating a feature branch with main
# Bring the latest main into your feature branch
git switch feature
git merge main
# Result: existing commits stay as they are, plus one
# new merge commit with two parents (feature and main)
git log --oneline --graph# Replay your feature commits on top of main
git switch feature
git rebase main
# Result: your commits get new IDs and follow
# main's latest commit in one straight line
git log --oneline --graph
# Already pushed the branch? Update it safely
git push --force-with-leaseReaders ask
Is rebase better than merge?
Neither is better overall. Rebase keeps history linear and tidy for private branches, while merge is safer for shared branches because it never rewrites commits.
When should you not use git rebase?
Don't rebase commits that other people have already pulled, such as those on main or another shared branch. Rewriting them forces everyone else to repair their local copies.
What is the difference between rebase and a squash merge?
A squash merge combines all of a branch's commits into one new commit on the target branch, while a rebase keeps each commit separate but moves them onto a new base.