Git Rebase vs Merge: What Is the Difference?
Understand git rebase vs merge — linear history vs preserved history, when to use each, and the golden rule for shared branches.
Expected Interview Answer
Git merge creates a new commit that joins two branch histories together, preserving the full original history, while git rebase rewrites your branch’s commits one by one on top of another branch’s tip, producing a clean, linear history without a merge commit.
A merge takes the tip of your feature branch and the tip of the target branch and creates a new commit with two parents, leaving both branches’ history exactly as it happened, including any divergence. A rebase instead replays each of your commits, one at a time, as if you had started your work from the current tip of the target branch, which rewrites commit hashes and creates entirely new commit objects. Merge is non-destructive and safe on shared branches because it never alters existing commits, while rebase should generally be avoided on commits that other people have already pulled, since rewriting shared history forces everyone else to reconcile diverging hashes. Teams typically merge feature branches into main to preserve an audit trail, but rebase a local feature branch onto main before opening a pull request to keep the history linear and easy to read.
- Keeps history linear and easy to read (rebase) or fully auditable (merge)
- Rebase produces a clean bisectable commit sequence
- Merge preserves the true chronological record of collaboration
- Choosing correctly avoids broken shared history for teammates
AI Mentor Explanation
A merge is like publishing a full match scorecard exactly as it happened — including a rain delay and a chaotic middle over — as one combined record joined to the tournament log. A rebase is like a commentator replaying the same innings as if it had been bowled fresh, back to back, with no rain delay noted, producing a tidier highlights reel. The merge keeps the true, messy sequence of events intact for the archive. The rebase produces a cleaner narrative but is a reconstructed version, not the literal original order of deliveries.
Step-by-Step Explanation
Step 1
Diverge from a common ancestor
Your feature branch and the target branch (e.g. main) share a common base commit, then each accumulates its own commits.
Step 2
Choose merge or rebase
git merge target creates a new merge commit joining both histories; git rebase target replays your commits onto the target tip.
Step 3
Resolve conflicts
Merge resolves conflicts once, in the merge commit; rebase may require resolving conflicts repeatedly, once per replayed commit.
Step 4
Integrate
Merge preserves original hashes and both parents; rebase produces new commit hashes and a linear history ready for a fast-forward merge.
What Interviewer Expects
- Clear distinction between preserving history (merge) and rewriting it (rebase)
- Understanding that rebase creates new commit hashes
- Awareness of the golden rule: never rebase commits already shared publicly
- Ability to explain when each strategy fits a team workflow
Common Mistakes
- Rebasing a branch that teammates have already pulled and built on
- Believing rebase and merge produce identical resulting code with no tradeoffs
- Not knowing how to resolve conflicts during an interactive rebase
- Forgetting that merge commits show explicit branch topology in git log --graph
Best Answer (HR Friendly)
“Merge and rebase both bring two branches together, but they do it differently. Merge keeps the full, honest history of what happened and when, including the branching, while rebase rewrites your commits so they look like they happened cleanly, one after another, on top of the latest code. We generally rebase our own local feature branches to keep things tidy before opening a pull request, but we never rebase a branch that someone else has already pulled, since that would rewrite history out from under them.”
Code Example
# Merge: creates a new merge commit, preserves both histories
git checkout main
git merge feature-branch
# Rebase: replays feature-branch commits onto main, linear history
git checkout feature-branch
git rebase main
# then fast-forward main
git checkout main
git merge feature-branch # now a fast-forward, no merge commit
# Golden rule: never rebase commits already pushed/shared
git log --graph --oneline --allFollow-up Questions
- What is the golden rule of rebasing, and why does it matter?
- How would you resolve a conflict that appears during an interactive rebase?
- What does git rebase -i let you do beyond a standard rebase?
- When would you prefer a fast-forward merge over a merge commit?
MCQ Practice
1. What does git rebase do to the commits being rebased?
Rebase replays each commit onto the new base commit, generating new commit objects with new hashes.
2. Why is rebasing shared, already-pushed commits considered risky?
Rewriting shared commit history forces every collaborator who already pulled those commits to reconcile diverging hashes.
3. What best distinguishes a merge commit from a rebase result?
A merge commit explicitly records two parent commits, while a rebase rewrites commits into a single-parent linear chain.
Flash Cards
What does git merge produce? — A new commit with two parents that joins two branch histories, preserving both.
What does git rebase produce? — A rewritten, linear sequence of commits replayed on top of a new base, with new hashes.
Golden rule of rebasing? — Never rebase commits that have already been pushed and pulled by others.
Why rebase a local feature branch? — To produce a clean, linear history before opening a pull request.