What is git cherry-pick and when to use it?

Git~3 min read

git cherry-pick copies a specific commit from one branch and applies it to your current branch as a new commit.

Theory

TL;DR

Cherry-pick is like picking one cherry off a branch without shaking the whole tree: you get exactly that one commit, nothing else.
It creates a new commit with the same changes, same message, and same author, but a fresh hash and your branch as the parent.
Main difference from merge: merge pulls in the entire branch history; cherry-pick takes just one commit's diff.
Decision rule: 1-3 commits you need selectively? Use cherry-pick. More than 5? Use merge or rebase.

Quick example

bash

# main has a bugfix, develop is missing it
git log --oneline main
# a1b2c3d Fix login crash  <- want this
# f4e5d6c Initial commit

git checkout develop
git cherry-pick a1b2c3d

git log --oneline develop
# b7c8d9e Fix login crash   <- new hash, same changes
# f4e5d6c Initial commit

The new commit on develop has the same message and diff but a different hash. The original stays on main untouched.

Git extracts the diff from the target commit (the exact patch of changes) and applies it to your working directory using a three-way merge. If it applies cleanly, Git commits automatically, preserving the original author, date, and message. If there are conflicts, it pauses and lets you resolve them. That three-way merge is why cherry-pick handles moved lines better than a plain git apply.

When to use

Security hotfix to a release branch: the patch landed on main, production is on release/v4.17, and you need that one commit there now.
Backport a specific bugfix: a stable branch gets one fix from main without pulling unfinished features along with it.
Extract one commit from a feature branch: the rest of the feature isn't ready, but one commit is safe to ship.
Avoid it when: you need 5+ commits. Cherry-picking many commits creates duplicate history and makes future merges painful. Use git merge or git rebase instead.

Common mistakes

Mistake 1: Cherry-picking a merge commit without -m

bash

git cherry-pick M
# fatal: commit M is a merge but no -m option given

A merge commit has two parents. Git doesn't know which side to diff against. Fix:

bash

git cherry-pick -m 1 M  # -m 1 = use the first (mainline) parent

Mistake 2: Using git commit after a conflict instead of --continue

bash

# You resolved the conflict, then:
git add .
git commit -m "Fixed"  # Wrong - loses cherry-pick metadata

# Correct:
git add .
git cherry-pick --continue

Mistake 3: Wrong range syntax

bash

git cherry-pick A..C   # Applies B and C, skips A
git cherry-pick A^..C  # Applies A, B, and C - usually what you want

The A..C notation excludes A. Add ^ to include it.

Mistake 4: Short hash collision on large repos

In repos with long histories (think Linux kernel), short hashes can collide. Verify before you pick:

bash

git log --oneline | grep a1b2c3
git cherry-pick a1b2c3d4e5f6  # use the full hash when unsure

Real-world usage

Kubernetes: cherry-picks CVE security patches from main to release-1.28 without pulling unrelated changes.
Node.js: applies crypto vulnerability fixes to v18.x stable from main (e.g., the v18.17.1 release).
React: ports isolated performance fixes from canary to stable/18 for specific edge cases.
Linux kernel: backports driver fixes to stable branches using commit ranges.

Follow-up questions

Q: What is the difference between git cherry-pick and git revert?
A: Cherry-pick applies a commit forward, adding its changes to your branch. Revert creates a new commit that undoes a previous commit's changes. Revert is safer on shared branches because it never rewrites history.

Q: How do you cherry-pick a range of commits including the start?
A: git cherry-pick A^..B. The A..B syntax excludes A, so you add ^ to include it.

Q: What happens to the original commit's author and date?
A: Both are preserved in the new commit. The committer and committer date reflect you and the current time.

Q: When does cherry-pick succeed where git apply would fail?
A: Cherry-pick uses three-way merge, so it handles cases where surrounding code has shifted or moved. git apply is a dumb patch and fails whenever context lines don't match exactly.

Q: In a monorepo with strict dependency tracking, why might teams prefer cherry-pick over merge for hotfixes?
A: Merge brings the full branch graph, which adds noise to the dependency history and can confuse automated scanners. Cherry-pick copies only the diff, keeping the commit graph linear and the change traceable to a single point.

Examples

Basic: Hotfix to a release branch

bash

# Security fix landed on main
git checkout main
git log --oneline -3
# a1b2c3d Fix: validate req.body size (prevents DoS)
# ...

# Apply to the production release branch
git checkout release/v4.17
git cherry-pick a1b2c3d

# Verify
git log --oneline -2
# f9e8d7c Fix: validate req.body size (prevents DoS)
# 3a2b1c0 Previous release commit

One command, one commit. The release branch gets the fix without absorbing everything else from main. This is the most common cherry-pick scenario in production codebases.

Intermediate: Handling a conflict during cherry-pick

bash

git checkout feature-stable
git cherry-pick b2c3d4e
# CONFLICT (content): Merge conflict in src/auth.js

# Open src/auth.js, resolve the conflict markers
# Then:
git add src/auth.js
git cherry-pick --continue
# [feature-stable e5f6g7h] Add token expiry check

If you change your mind mid-way, git cherry-pick --abort restores the branch to exactly the state before you started. I've reached for --abort more than once when a conflict made it clear the commit depended on other changes that weren't in the target branch yet.

Short Answer

Interview ready

Premium

A concise answer to help you respond confidently on this topic during an interview.

Finished reading?