Lesson 16 of 30

Cherry-Picking

Q: A critical bug fix needs to go out on both main and a release branch that's already been cut. Walk through how you'd handle that with git, and what could go wrong.

A strong answer covers: Fix it once on one branch, then git cherry-pick the commit hash onto the other branch(es) rather than re-writing the fix by hand; Understands cherry-pick creates a new commit with a new hash — the original commit is untouched; Knows a cherry-pick can conflict just like a merge, and describes resolving it (edit, git add, --continue); Mentions -x or some way of tracking provenance so the duplication is traceable later.

Take one specific commit from another branch without merging everything else — the tool for landing a hotfix in two places at once.

12 min read

Check your understanding

Every option explains itself — why the right one is right, and why each wrong one is wrong. Miss one and it comes back later on a spaced-repetition schedule.

No quiz for this one — it's a practical topic

This topic is about judgment and practical tradeoffs more than a single right answer — a mock interview is the better way to test yourself on it.

Be interviewed on this →

Stuck? Ask the AI tutor

Hints without spoilers, and a plain explanation of why a wrong answer was wrong — answered only from this lesson. Free account, no card.

Interview questions on Cherry-Picking

What interviewers actually ask about this, and what a strong answer has to cover.

A critical bug fix needs to go out on both main and a release branch that's already been cut. Walk through how you'd handle that with git, and what could go wrong.

A strong answer covers

Fix it once on one branch, then git cherry-pick the commit hash onto the other branch(es) rather than re-writing the fix by hand
Understands cherry-pick creates a new commit with a new hash — the original commit is untouched
Knows a cherry-pick can conflict just like a merge, and describes resolving it (edit, git add, --continue)
Mentions -x or some way of tracking provenance so the duplication is traceable later

Likely follow-ups

If release/2.4 and main keep diverging and you're cherry-picking fixes back and forth every week, is that still the right tool? What would you reach for instead?
How would cherry-picking a merge commit be different from cherry-picking a regular commit?
Someone on your team cherry-picked a commit but forgot -x. Six months later, how would you even figure out where that fix originally came from?

Practice these with the AI interviewer →

The plain-language idea

git cherry-pick takes a single commit that exists somewhere else in the repo and replays it on top of your current branch. It's a merge, scoped down to one commit — you get that commit's changes without pulling in everything else that branch has done.

The name is literal: you're picking one cherry off a tree full of them, not the whole branch.

See it in a real thing: a hotfix that needs to land on `main` and `release/2.4`

Say a null-check bug shipped, and it exists both in main (where the team is doing normal work) and in release/2.4 (a stabilized branch already cut for a release). You fix it once, on main:

git switch main
git commit -m "fix: guard against null user in formatDisplayName"
# commit hash: a1b2c3d

Now you need that exact fix on release/2.4 too, without dragging every other main commit since the branch split:

git switch release/2.4
git cherry-pick a1b2c3d

Git replays a1b2c3d's diff onto release/2.4 and creates a new commit with a new hash — same changes, same message by default, different parent, different SHA. git log --oneline on release/2.4 now shows the fix as its own commit, not a merge:

$ git log --oneline -3
f9e8d7c fix: guard against null user in formatDisplayName
c4b3a21 chore: bump version to 2.4.1
88ab001 fix: correct pagination offset on last page

Cherry-pick a range with git cherry-pick A^..B (careful with the ^) or pick several by listing hashes: git cherry-pick a1b2c3d e5f6a7b.

What people usually miss

Watch out

A cherry-pick conflict looks exactly like a merge conflict — resolve it the same way. Git pauses mid-pick, drops conflict markers (<<<<<<<, =======, >>>>>>>) into the affected files, and waits. Fix the file, git add it, then git cherry-pick --continue. Changed your mind? git cherry-pick --abort puts you back to before you started.
Cherry-picking creates a new commit, it doesn't move the old one. The original commit still exists on its original branch with its original hash. You now have the same logical change living as two different commits in two different histories — that's expected, not a bug.
Repeated cherry-picks across long-lived branches accumulate. If release/2.4 and main diverge further and you keep cherry-picking one-off fixes, you're manually re-deriving what a proper merge or rebase would do automatically — fine for a rare hotfix, painful as a regular workflow. If you're cherry-picking constantly between two branches, that's usually a sign you should be merging instead.

The genealogy: it's a merge with the scope turned down

Cherry-pick uses the same three-way-diff machinery as a regular merge — it just applies to one commit's diff instead of the full set of commits reachable from a branch tip. Understanding how a merge conflict happens under the hood is exactly what tells you why a cherry-pick can conflict too, and why the resolution mechanics are identical.