Merge vs Rebase
Git merge vs rebase explained with commands and when to use each, plus why rebase rewrites history and merge does not.
Merge combines two branches by creating a new merge commit and keeps the full history exactly as it happened. Rebase replays your commits on top of another branch, producing a clean straight line but rewriting commit history.
Merge vs Rebase at a glance
| Merge | Rebase | |
|---|---|---|
| History shape | Preserves branching, shows a merge commit | Produces a straight, linear history |
| Commit hashes | Unchanged | Rewritten, new hashes for replayed commits |
| Safety on shared branches | Safe, does not rewrite history | Risky if others already pulled the branch |
| Conflict resolution | Resolved once, in the merge commit | May need resolving repeatedly, per replayed commit |
| Command | git merge feature-branch | git rebase main |
| Best used for | Integrating a finished feature into main | Cleaning up a branch before opening a pull request |
When to use each
Choose Merge when
- You are combining a completed feature branch into main and want an honest history.
- Other people are already working off the branch you are merging.
- You want a single command with no risk of rewriting shared history.
Choose Rebase when
- You want a clean, linear commit history before opening a pull request.
- You are updating your local feature branch with the latest main before merging.
- You are the only person working on the branch, so rewriting history is safe.
What each command actually does
git merge takes the tip of both branches and creates a new commit that has two parents, joining the histories together. Nothing about the existing commits changes. git rebase instead takes your commits, temporarily sets them aside, moves your branch to the tip of the target branch, and replays your commits one by one on top of it. The result looks like you started your work from that new position.
# merge: keeps history, creates a merge commit
git checkout main
git merge feature-branch
# rebase: rewrites history onto main
git checkout feature-branch
git rebase mainThe golden rule interviewers look for is never rebase a branch that other people have already pulled. Since rebase changes commit hashes, anyone else working off the old commits will get a confusing history mismatch.
Frequently asked questions
Which one should I use as a beginner?
Start with merge. It is safer because it never rewrites history, and you avoid the risk of a rebase going wrong on a shared branch.
Does rebase lose commits?
It does not lose the changes, but it does replace old commits with new ones that have different hashes. If you force push after a rebase, anyone with the old commits can run into problems.
What is an interactive rebase used for?
git rebase -i lets you reorder, squash, edit, or drop commits before they land on another branch, which is commonly used to clean up messy commit history before a pull request.
Want more interview ready comparisons?
Browse every Merge vs Rebase style breakdown, or explore the full question library.
All comparisons Browse questions