Cherry-pick vs merge vs rebase for backporting fixes

Fast recall

Quick revision

Core answer

Cherry-pick is almost always the right tool for backporting: it copies one or more specific commits to a target branch without bringing along unrelated changes. Merge would pull in the entire branch history, and rebase would replay all commits since the divergence point — both are too broad for a targeted backport. Reserve merge and rebase for integrating full feature work.

Backporting a bug fix to a maintenance branch requires copying a specific commit without bringing along unrelated history. Cherry-pick is the right tool for this — the other two options bring far more than you want.

Cherry-pick — surgical backporting

git cherry-pick -x copies one specific commit to the current branch and appends the original SHA to the commit message — the -x creates a traceable link from the maintenance branch commit back to the main-branch source
Cherry-pick is correct when the fix is a single, well-scoped commit on main; if the fix spans multiple commits, cherry-pick them in order so the branch compiles at each step
When the target branch diverges enough that the patch does not apply cleanly, write a standalone fix for the older context rather than importing assumptions from main that do not hold there

Why not merge for backporting

Merging main into v2.x brings three months of new features, API changes, and dependency upgrades along with the one security fix — the maintenance branch loses its purpose of being a stable, minimal surface
Merge commits also obscure what was actually ported, making audit trails harder to produce for security teams

Why not rebase for backporting

Rebase replays every commit since the branch diverged — on a maintenance branch that split six months ago, that could be hundreds of commits replayed onto a codebase with different structure
Rebase rewrites SHAs and requires a force-push on a shared branch that other engineers have checked out

The key enabling practice: keeping commits on main small and logically cohesive. A fix committed alongside a refactor cannot be cherry-picked cleanly. Teams that commit features as single atomic units spend far less time on backport conflicts.

Interview-ready guide

Interview answer

Cherry-pick — surgical backporting

git cherry-pick -x copies one specific commit to the current branch and appends the original SHA to the commit message — the -x creates a traceable link from the maintenance branch commit back to the main-branch source
Cherry-pick is correct when the fix is a single, well-scoped commit on main; if the fix spans multiple commits, cherry-pick them in order so the branch compiles at each step
When the target branch diverges enough that the patch does not apply cleanly, write a standalone fix for the older context rather than importing assumptions from main that do not hold there

Why not merge for backporting

Merging main into v2.x brings three months of new features, API changes, and dependency upgrades along with the one security fix — the maintenance branch loses its purpose of being a stable, minimal surface
Merge commits also obscure what was actually ported, making audit trails harder to produce for security teams

Why not rebase for backporting

Rebase replays every commit since the branch diverged — on a maintenance branch that split six months ago, that could be hundreds of commits replayed onto a codebase with different structure
Rebase rewrites SHAs and requires a force-push on a shared branch that other engineers have checked out

03 · Deep dive