Git Rebase vs Merge
Last updated
Both git merge and git rebase combine work from one branch into another. git merge ties the two histories together with a merge commit, preserving exactly what happened. git rebase replays your commits one by one on top of the other branch, producing a clean, linear history - but rewriting your commits in the process.
The golden rule: never rebase commits others have already pulled. Try both in the terminal playground - a real shell in your browser.
Side by side
| Behavior | git merge | git rebase |
|---|---|---|
| History shape | Branching, with a merge commit | Linear |
| Rewrites commits | No | Yes |
| Safe on shared branches | Yes | No |
| Preserves exact history | Yes | No |
| Easy to trace when things merged | Yes | Harder |
Syntax
| Command | What it does |
|---|---|
git merge feature | Merge feature into the current branch |
git merge --no-ff feature | Always create a merge commit |
git rebase main | Replay current branch's commits on main |
git rebase -i HEAD~3 | Interactively edit the last 3 commits |
git rebase --abort | Cancel a rebase in progress |
Git rebase vs merge FAQ
What is the difference between git rebase and git merge?
git merge combines two branches by creating a new merge commit that joins their histories, keeping the exact record of what happened. git rebase instead moves your commits so they replay on top of another branch, producing a straight-line history but rewriting those commits with new hashes. Merge preserves history; rebase rewrites it for cleanliness.When should I use merge and when should I use rebase?
Use merge to integrate a finished branch (especially a shared one) - it's safe and non-destructive. Use rebase to tidy up your own local commits before sharing them, or to update a feature branch onto the latest
main for a clean history. Many teams rebase locally, then merge into main.What is the golden rule of rebasing?
Never rebase commits that others have already based work on - typically anything you've pushed to a shared branch. Because rebase rewrites commits, doing so forces everyone else to reconcile a diverged history. Rebase freely on local, unpushed commits; use merge (or revert) for anything already public.
Does rebase or merge cause fewer conflicts?
Neither avoids conflicts, but they surface them differently. A merge resolves all conflicts once, in the merge commit. A rebase can ask you to resolve conflicts commit by commit as each one is replayed. The total work is similar; rebase just spreads it out.
Can I practice this online?
Yes. Open the terminal playground to run
git merge and git rebase in a real shell in your browser - nothing to install. Coddy's free interactive Git course also covers merging and rebasing step by step.