What is the difference between git merge and git rebase?

Why Interviewers Ask This

Interviewers use this question to quickly assess whether a candidate has the foundational knowledge required for Git & GitHub development. It reveals whether you understand the building blocks that more complex concepts rely on.

Answer

Both merge and rebase integrate changes from one branch into another but differ in how they do it and the resulting history. git merge: combines branches by creating a merge commit with two parents. Preserves complete, accurate history — you can see exactly when and how branches diverged and joined. The history tells the true story. Results in a "diamond" shaped graph. Best for: shared branches (main, develop), feature branch merges into main, when you want to preserve the full history. git rebase: re-applies commits from one branch on top of another, rewriting commit history. The feature branch commits are replayed as if they were created after the latest main commit. Creates a clean, linear history — no merge commits, looks like development happened sequentially. But it rewrites commit SHAs (history is altered). Best for: cleaning up local feature branches before merging, keeping feature branch up-to-date with main. Golden rule of rebase: never rebase public/shared branches. Only rebase your own local, unpushed commits. If you rebase pushed commits, you rewrite history everyone else has, causing chaos. Use interactive rebase (git rebase -i) to clean up commits before a PR.

Pro Tip

This topic has Git & GitHub-specific nuances that differ from general programming. Highlighting those nuances in your answer shows expertise rather than generic knowledge.