Git merge vs rebase — when to use each

Fast recall

Quick revision

Core answer

Use merge to preserve the full history of parallel development and for integrating long-lived feature branches into main. Use rebase to produce a cleaner, linear commit history on short-lived topic branches before merging, or to keep a feature branch up-to-date with main without introducing merge commits.

Merge and rebase both integrate changes from one branch into another — the code result is identical. The difference is entirely in what git log looks like afterward and whether history is ever rewritten.

Merge — preserving honest history

Merge creates a merge commit that records exactly when the feature branch entered the main branch — during an incident, that bookmark tells you which commit introduced a change and when
Fast-forward merges skip the merge commit when the branch is linear, but the default --no-ff flag keeps it, making integrations visible in the graph
Merge never rewrites pushed history, which makes it safe to use on any shared branch without coordinating with teammates

Rebase — rewriting for a cleaner story

Rebase replays your commits on top of the target branch, producing a linear history as though the feature was developed after all main-branch changes — reviewers see purposeful commits, not tangled WIP entries mixed with upstream merges
The critical rule: never rebase a branch that others have checked out — replaying commits produces new SHAs, and a force-push after rebase silently overwrites any commits your teammates added on top of the old SHAs
Use --force-with-lease instead of --force when pushing after a rebase — it checks that no one pushed to the remote branch while you were rebasing and fails safely if they did

Squash-and-merge — the practical compromise

Squash-and-merge collapses the entire PR into one commit on main, attaching the PR number — you get linear history without the discipline of clean individual commits throughout development
The trade-off: git bisect and git blame become less precise since the full development history is collapsed; for a PR that touched ten files it can be harder to isolate which change introduced a bug

Pick one convention, encode it in branch protection rules, and stop re-deciding it in every code review.

Interview-ready guide

Interview answer

Merge — preserving honest history

Merge creates a merge commit that records exactly when the feature branch entered the main branch — during an incident, that bookmark tells you which commit introduced a change and when
Fast-forward merges skip the merge commit when the branch is linear, but the default --no-ff flag keeps it, making integrations visible in the graph
Merge never rewrites pushed history, which makes it safe to use on any shared branch without coordinating with teammates

Rebase — rewriting for a cleaner story

Rebase replays your commits on top of the target branch, producing a linear history as though the feature was developed after all main-branch changes — reviewers see purposeful commits, not tangled WIP entries mixed with upstream merges
The critical rule: never rebase a branch that others have checked out — replaying commits produces new SHAs, and a force-push after rebase silently overwrites any commits your teammates added on top of the old SHAs
Use --force-with-lease instead of --force when pushing after a rebase — it checks that no one pushed to the remote branch while you were rebasing and fails safely if they did

Squash-and-merge — the practical compromise

Squash-and-merge collapses the entire PR into one commit on main, attaching the PR number — you get linear history without the discipline of clean individual commits throughout development
The trade-off: git bisect and git blame become less precise since the full development history is collapsed; for a PR that touched ten files it can be harder to isolate which change introduced a bug

Pick one convention, encode it in branch protection rules, and stop re-deciding it in every code review.

03 · Deep dive