What is the difference between git merge and git rebase?
Understand git merge vs git rebase: merge preserves history with a merge commit, rebase rewrites commits into a clean linear history. Learn when to use each.
Expected Interview Answer
git merge combines two branches by creating a new merge commit that ties their histories together, preserving the original branch structure, while git rebase moves your branch's commits so they replay on top of another branch, producing a linear history.
Merge is non-destructive: it keeps every commit exactly as it happened and adds a merge commit that has two parents, which faithfully records that the branches diverged and rejoined. Rebase rewrites history by creating brand-new commits with new hashes, giving a clean straight line but losing the record of when work actually branched. The golden rule is to never rebase commits that have already been pushed and shared, because rewriting shared history breaks collaborators' clones.
- Merge preserves true history and is safe for shared branches
- Merge is traceable — a merge commit shows exactly when branches joined
- Rebase produces a clean, linear, easy-to-read history
- Rebase avoids clutter from many merge commits
- Choosing the right one keeps history both accurate and readable
AI Mentor Explanation
Merge is like keeping two separate innings scorecards and stapling a summary sheet on top that says how both innings combined into the final result — every original ball stays on record. Rebase is like rewriting your second innings ball-by-ball as if it had been played straight after the first, producing one continuous scorecard. It reads cleaner, but the honest fact that two innings ran on different days is quietly erased.
Step-by-Step Explanation
Step 1
Understand the divergence
Both branches share a common ancestor commit, then each added its own commits independently.
Step 2
Merge creates a merge commit
git merge feature ties the two histories together with a new commit that has two parents, keeping all commits unchanged.
Step 3
Rebase replays commits
git rebase main takes your feature commits and reapplies them one by one on top of main's latest commit as new commits.
Step 4
Handle conflicts
Merge resolves conflicts once in the merge commit; rebase may ask you to resolve conflicts per replayed commit.
Step 5
Apply the golden rule
Rebase only local, unpushed commits — never rewrite history that others have already pulled.
What Interviewer Expects
- Merge preserves history; rebase rewrites it into a linear form
- Merge creates a merge commit with two parents
- Rebase creates new commits with new hashes
- Awareness of the golden rule of rebasing shared branches
- When to prefer each in a real workflow
Common Mistakes
- Rebasing commits that have already been pushed and shared
- Thinking rebase and merge produce identical history
- Believing rebase never causes conflicts
- Assuming a merge commit is always unnecessary clutter
Best Answer (HR Friendly)
“Both commands combine work from different branches. Merge keeps the full record of how the branches came together by adding a special merge point, while rebase rewrites the history to make it look like one clean straight line. Merge is safer for shared work; rebase gives tidier history for your own local changes.”
Code Example
# Bring feature branch changes into main with a merge commit
git checkout main
git merge feature
# Creates a new merge commit that preserves both histories# Replay feature commits on top of the latest main
git checkout feature
git rebase main
# Resolve any conflicts, then continue
git rebase --continue
# Result is a linear history with new commit hashesFollow-up Questions
- What is the golden rule of rebasing?
- What is an interactive rebase and when would you use it?
- How does a fast-forward merge differ from a three-way merge?
- How do you undo a rebase that went wrong?
- When would you prefer merge over rebase in a team workflow?
MCQ Practice
1. What does git merge create when combining two diverged branches?
A non-fast-forward merge produces a merge commit that has two parents, tying both branch histories together while preserving all original commits.
2. What is the key risk of git rebase?
Rebase creates new commits with new hashes, rewriting history — doing this to already-pushed shared commits breaks collaborators' clones.
3. Which outcome best describes git rebase?
Rebase replays commits on top of another branch to produce a straight, linear history without a merge commit.
Flash Cards
What does git merge preserve? — The full original history, adding a merge commit with two parents.
What does git rebase produce? — A clean linear history by replaying commits as new commits with new hashes.
What is the golden rule of rebasing? — Never rebase commits that have already been pushed and shared.
Which is safer for shared branches, merge or rebase? — Merge — it does not rewrite existing history.