What is git rebase and how does it differ from merge
Both integrate changes from one branch into another. Merge creates a merge commit joining two histories (non-destructive, preserves the actual history). Rebase replays your commits on top of the target branch, creating a linear history but rewriting commits. Never rebase shared/public branches.
git merge and git rebase both integrate changes from one branch into another — they differ in how the history looks afterward.
git merge
Combines two branches by creating a new merge commit with two parents, tying the histories together.
main: A───B───C───────M
\ /
feature: D───E- Non-destructive — existing commits are untouched;
DandEstay exactly as they were. - History shows what actually happened, including the branch topology.
- Can produce a "messy," non-linear graph with many merge commits.
git rebase
Replays your branch's commits one by one on top of the target branch's tip.
Before: main: A─B─C feature: A─B─D─E
After: main: A─B─C feature: A─B─C─D'─E' (D', E' are NEW commits)- Linear history — no merge commits; looks like the work happened sequentially.
- Rewrites history —
D'andE'are new commits with new hashes (same changes, new parentage). - Cleaner
git log, easiergit bisect.
The key differences
| Merge | Rebase | |
|---|---|---|
| History | preserved, non-linear, merge commits | rewritten, linear, no merge commits |
| Commits | unchanged | new hashes (rewritten) |
| Traceability | shows real branch topology | looks sequential |
| Conflicts | resolved once, in the merge commit | may resolve per replayed commit |
| Safety | always safe | dangerous on shared branches |
The golden rule
Never rebase commits that others have based work on (shared/public branches). Rebasing rewrites history; if others have the old commits, their history and yours diverge — a mess. Rebase only your own local, unpushed work.
Practical workflow
- Rebase your feature branch onto
mainbefore opening/updating a PR — keeps your branch current and the eventual merge clean. (git pull --rebasedoes this for keeping a branch up to date.) - Merge the PR into
main(often a squash-merge or merge commit) —main's shared history is preserved. git rebase -i(interactive) to clean up local commits — squash, reword, reorder — before sharing.
How to answer
"Both integrate one branch into another. Merge creates a merge commit joining the histories — non-destructive, but non-linear. Rebase replays your commits on top of the target — linear, clean history, but it rewrites commits with new hashes. The golden rule: rebase only your own local work, never shared/public branches. Common workflow: rebase my feature branch onto main to stay current, merge the PR into main."
Follow-up questions
- •Why is rebasing a shared branch dangerous?
- •What does interactive rebase let you do?
- •What's the difference between git pull and git pull --rebase?
- •When would you prefer a merge commit over a linear history?
Common mistakes
- •Rebasing a branch others have already pulled — diverging histories.
- •Thinking rebase and merge produce the same commits (rebase rewrites them).
- •Force-pushing a rebased shared branch and clobbering others' work.
- •Not understanding conflicts may need resolving per-commit during rebase.
Performance considerations
- •
Edge cases
- •Conflicts during a multi-commit rebase (resolve, git rebase --continue).
- •Aborting a rebase (git rebase --abort).
- •Rebasing after others have already merged your old commits.
Real-world examples
- •git pull --rebase to keep a feature branch current without merge-commit noise.
- •Interactive rebase to squash WIP commits into one clean commit before a PR.