What is git rebase and how does it differ from git 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.

5 min read·~6 min to think through

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; D and E stay 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' and E' are new commits with new hashes (same changes, new parentage).
Cleaner git log, easier git 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 main before opening/updating a PR — keeps your branch current and the eventual merge clean. (git pull --rebase does 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.

Senior engineer discussion

Seniors explain the mechanism (merge = merge commit joining histories; rebase = replay producing new commits) and state the golden rule clearly. They describe a sane team workflow — rebase local work to stay current, merge PRs into shared branches — and mention interactive rebase for history hygiene.