What is Git Cherry-Pick?
Learn what git cherry-pick does, how it replays a single commit onto another branch, and when to use it for hotfixes and backporting changes.
Expected Interview Answer
`git cherry-pick <commit>` applies the changes introduced by one specific commit from another branch onto your current branch, creating a brand-new commit with the same content but a different hash and parent.
Under the hood, Git computes the diff that the target commit introduced relative to its own parent, then replays that diff on top of your current HEAD, producing a new commit object; the original commit is untouched and still exists on its original branch. This is useful when you need just one fix, say a critical bug patch, without pulling in an entire branch's unrelated history, such as backporting a hotfix from `main` into a release branch. Because the replayed commit has a new hash, cherry-picking the same logical change onto multiple branches is normal and expected, though it can lead to duplicate-looking commits if you later merge those branches together. If the target commit's changes conflict with your current branch, Git pauses and lets you resolve the conflict just like a merge, then you continue with `git cherry-pick --continue`.
- Ports a single fix without merging unrelated history
- Preserves the original author and commit message by default
- Ideal for backporting hotfixes to release or LTS branches
- Works on a range of commits with `cherry-pick A..B`
- Leaves the source branch and its history completely unchanged
AI Mentor Explanation
Cherry-pick is like replaying just one standout shot from a rain-abandoned warm-up match into the highlights reel of the real tournament, without importing the rest of that unofficial game. The shot is recreated fresh in the new context, keeping the tournament's own sequence of overs completely intact.
Step-by-Step Explanation
Step 1
Identify the commit
Find the SHA-1 of the specific commit you need, usually with `git log` on the branch that has the fix, e.g. `abc1234`.
Step 2
Switch to the target branch
`git switch release-2.1` checks out the branch that needs the fix applied on top of its own history.
Step 3
Run cherry-pick
`git cherry-pick abc1234` replays that commit's diff on top of your current HEAD and creates a new commit.
Step 4
Resolve conflicts if any
If the diff doesn't apply cleanly, Git pauses; resolve the conflicting files, `git add` them, then run `git cherry-pick --continue`.
Step 5
Verify and push
Check `git log` to confirm the new commit exists with the expected content, then `git push` the release branch.
What Interviewer Expects
- Explains cherry-pick applies one commit's diff onto another branch
- Knows the resulting commit gets a new hash, not the original one
- Understands the original commit and branch are untouched
- Can describe a real use case like backporting a hotfix
- Knows how to resolve a conflict during cherry-pick
Common Mistakes
- Thinking cherry-pick moves the commit instead of copying it
- Assuming the cherry-picked commit keeps the same SHA-1 as the original
- Cherry-picking a whole range without checking for interdependent commits
- Not resolving conflicts properly and abandoning with `--abort` unnecessarily
- Overusing cherry-pick instead of a proper merge, causing duplicate history
Best Answer (HR Friendly)
“Cherry-pick lets a developer grab one specific change from one branch and apply it to another, without bringing over anything else. It's commonly used to quickly patch a live release with a bug fix that was already made somewhere else, without merging in unrelated work.”
Code Example
$ git log --oneline main | head -3
abc1234 Fix null pointer in payment handler
9f8e7d6 Add logging to checkout flow
5c4b3a2 Update dependencies
$ git switch release-2.1
$ git cherry-pick abc1234
[release-2.1 e1f2a3b] Fix null pointer in payment handler
Date: Sun Jul 26 2026
1 file changed, 4 insertions(+), 1 deletion(-)
$ git push origin release-2.1Follow-up Questions
- How is cherry-pick different from a merge or rebase?
- What happens if a cherry-picked commit conflicts with the target branch?
- How do you cherry-pick a range of commits?
- How does cherry-picking a merge commit work with the `-m` flag?
- Why might cherry-picking too often cause duplicate commits after a later merge?
MCQ Practice
1. What does `git cherry-pick <commit>` do?
Cherry-pick replays the diff introduced by the target commit on top of the current HEAD, producing a new commit with a new hash.
2. After cherry-picking, what happens to the original commit?
Cherry-pick copies the change; the original commit and its branch are left completely unchanged.
3. A common real-world use case for cherry-pick is:
Cherry-pick is frequently used to apply one specific fix, such as a critical bug patch, onto a release or maintenance branch without merging unrelated commits.
Flash Cards
What does git cherry-pick do? — Applies the changes from a specific commit onto the current branch as a brand-new commit.
Does the cherry-picked commit keep the same hash? — No — it gets a new SHA-1 since its parent and context differ from the original.
What happens to the source commit after cherry-picking? — It is untouched; it still exists on its original branch exactly as before.
Name one common use case for cherry-pick. — Backporting a specific bug fix from main into a release or hotfix branch.