git cherry-pick: Applying Specific Commits to Another Branch

So far, moving changes between branches has meant merging or rebasing an entire branch's commits. Sometimes you want something much more surgical: applying just *one specific commit* from one branch onto another, without bringing along everything else that branch contains. That's exactly what `git cherry-pick` does.

Learning Objectives

Apply a single specific commit from one branch onto another using git cherry-pick.
Cherry-pick multiple commits in one operation.
Understand how a cherry-picked commit relates to (and differs from) its original.
Recognize common real-world scenarios where cherry-pick is the appropriate tool.

Key Terms to Know Before Using git cherry-pick

git cherry-pick <commit>: Applies the changes introduced by a specific commit onto your current branch, creating a new commit with the same changes but a different hash.
Backport: The practice of applying a fix made on one branch (typically a newer one) back onto an older, still-supported branch, commonly done via cherry-pick.
Cherry-pick conflict: A conflict that can occur if the cherry-picked commit's changes overlap with content that differs between the source and target branches.

How git cherry-pick Actually Works

`git cherry-pick <commit-hash>` takes the changes introduced by exactly that one commit and applies them to your current branch, creating a new commit with the same change content and message, but — like a rebased commit — a **new hash**, since it's technically a new commit object with a different parent (your current branch's tip, rather than wherever the original commit's parent was):

```
git switch main
git cherry-pick a1b2c3d
```

This is fundamentally different from merging or rebasing an entire branch: cherry-pick operates on **one specific commit** (or an explicitly listed sequence of them), leaving every other commit on the source branch completely untouched and unaffected on your current branch.

Multiple commits can be cherry-picked in a single operation by listing them:

```
git cherry-pick a1b2c3d 9f8e7d6 3c4d5e6
```

Just like a rebase, a cherry-pick can encounter a **conflict** if the commit's changes overlap with content that differs between where it originally existed and your current branch — resolved using the same familiar process (edit, stage, then `git cherry-pick --continue` to proceed, or `git cherry-pick --abort` to cancel).

The most common real-world use case is a **backport**: fixing a critical bug on your primary development branch, then cherry-picking that exact fix commit onto an older, still-supported release branch that needs the same fix but shouldn't receive all of the primary branch's other, unrelated ongoing changes. For example, if a security vulnerability is fixed on `main`, and your team still maintains and ships patches for `release/2.x`, cherry-picking just that specific fix commit onto `release/2.x` applies the fix there without pulling in every other unrelated change that has happened on `main` since those branches diverged.

Other common scenarios: recovering a single specific useful commit from a branch that's otherwise being abandoned or deleted, or applying one specific hotfix commit to multiple different long-running branches independently (connecting back to Module 3's discussion of hotfix branches, which sometimes need their fix applied to more than one destination).

A detail worth understanding, similar to rebase: because a cherry-picked commit is a genuinely new commit object with a new hash, Git has no inherent memory that it's 'the same fix' as the original — if you later merge the two branches together, Git generally handles this gracefully (recognizing the changes are already present and not re-applying them, or flagging an unusual conflict only in edge cases), but it's still useful to understand that cherry-picking creates a duplicate, independent commit rather than somehow 'sharing' the original across branches.

git cherry-pick: Visual Walkthrough

Draw two separate branch lines: 'main' with five commits, and 'release/2.x' with three unrelated commits, diverged much earlier from main. Highlight one specific commit on main, C4, labeled 'fix: critical security patch'. Draw an arrow labeled 'git cherry-pick C4' from main directly to the tip of 'release/2.x', producing a NEW commit C4' on release/2.x with the same changes and message but a different hash and different parent. Caption: 'Only C4's changes are applied — none of main's other commits (C1, C2, C3, C5) affect release/2.x.'

git cherry-pick vs git merge: Key Differences

Aspect	git merge (entire branch)	git cherry-pick (single commit)
Scope	Brings in ALL of a branch's unique commits	Applies exactly ONE specified commit
Resulting commit hash	Original commits preserved, plus a merge commit	A brand-new commit with a new hash
Typical use case	Integrating a completed feature branch	Backporting a specific fix to another branch
Can conflict?	Yes, if branches diverged with overlapping changes	Yes, if the commit's changes overlap with differing content

git cherry-pick: Command Syntax and Examples

# Backport a critical fix from main to an older release branch
git switch release/2.x
git cherry-pick a1b2c3d
# [release/2.x abc1234] fix: critical security patch
#  (same message, but a NEW commit hash — abc1234, not a1b2c3d)

# Cherry-pick multiple commits at once
git cherry-pick a1b2c3d 9f8e7d6

# Handling a conflict during cherry-pick
git cherry-pick a1b2c3d
# CONFLICT (content): Merge conflict in payment.js
# (resolve the conflict, exactly as in a merge or rebase)
git add payment.js
git cherry-pick --continue

# Cancel an in-progress cherry-pick
git cherry-pick --abort

Breaking Down the git cherry-pick Example

The backport example shows cherry-picking a specific security fix commit (`a1b2c3d`) from `main` onto the older `release/2.x` branch, producing a new commit with the same message and changes but a genuinely different hash (`abc1234`), since it's technically a new commit object. The multi-commit example shows applying several commits in one operation, in the order listed. The conflict-handling block mirrors the same resolve-then-continue pattern from rebase, using cherry-pick's own `--continue` and `--abort` variants specifically for this operation.

How git cherry-pick Is Used on Real Engineering Teams

Backporting critical security fixes to older, still-supported release branches is one of the most common and important real-world uses of cherry-pick across the software industry, especially for products maintaining multiple supported versions simultaneously.
Open-source maintainers sometimes cherry-pick a single valuable commit from an otherwise abandoned or rejected pull request, preserving that one useful change without merging the rest of the contribution.
Release engineering teams managing parallel release branches (e.g., a stable branch and a development branch) frequently use cherry-pick to apply specific hotfixes to the stable branch independently of ongoing development work.
Some teams use cherry-pick when a commit was accidentally made on the wrong branch, applying it to the correct branch and then removing it from the original (via reset or rebase, covered in upcoming lessons).

git cherry-pick Interview Questions and Answers

Q1. What does git cherry-pick do, and how is it different from merging a branch?

It applies the changes from one specific commit onto your current branch, creating a new commit with the same content and message but a new hash, leaving every other commit on the source branch untouched. This differs fundamentally from merging, which brings in all of a branch's unique commits at once, typically with a merge commit recording the integration.

Q2. What is a backport, and how does cherry-pick support this workflow?

A backport applies a fix made on one branch (typically the primary development branch) back onto an older, still-supported branch that needs the same fix without receiving all the primary branch's other unrelated changes. Cherry-picking just the specific fix commit onto the older branch accomplishes exactly this, without pulling in unrelated history.

Q3. Does a cherry-picked commit share the same hash as the original commit it was copied from?

No. Because the cherry-picked commit has a different parent (the current branch's tip, rather than the original commit's actual parent), it's technically a new commit object, resulting in a new hash, even though its change content and message are identical to the original.

git cherry-pick Quiz: Test Your Understanding

1. What does git cherry-pick <commit> do?

Merges an entire branch's history into the current branch
Applies the changes from one specific commit onto the current branch, creating a new commit
Permanently deletes the specified commit
Renames a branch

Answer: B. Applies the changes from one specific commit onto the current branch, creating a new commit

Explanation: Cherry-pick operates on exactly one specified commit, applying its changes to the current branch as a new commit, leaving all other commits on the source branch untouched.

2. What is a common real-world use case for git cherry-pick?

Deleting a repository
Backporting a specific fix to an older, still-supported release branch
Renaming a remote
Creating a new GitHub account

Answer: B. Backporting a specific fix to an older, still-supported release branch

Explanation: Cherry-pick is commonly used to apply a specific bug or security fix from a primary development branch onto an older release branch, without pulling in all the primary branch's other unrelated changes.

3. Does a cherry-picked commit have the same hash as the original commit?

Yes, always identical
No — it's a new commit object with a different parent, resulting in a new hash
Only if there's no conflict during the cherry-pick
Hashes are not used for cherry-picked commits

Answer: B. No — it's a new commit object with a different parent, resulting in a new hash

Explanation: Since the cherry-picked commit has a different parent commit (the tip of the branch it was applied to), it's technically a new commit object, resulting in a different hash despite identical content and message.

Common git cherry-pick Mistakes Beginners Make

Assuming cherry-pick brings along other related commits automatically, when it applies only the exact commit(s) explicitly specified.
Forgetting that a cherry-picked commit has a new hash, leading to confusion when later comparing or merging branches that both contain 'the same' fix under different hashes.
Not resolving cherry-pick conflicts using the correct --continue/--abort commands, and instead trying to manually recover from a stuck, in-progress cherry-pick.
Overusing cherry-pick as a substitute for a proper merge when integrating an entire completed feature, rather than reserving it for the surgical, single-commit use cases it's actually designed for.

git cherry-pick: Exam-Ready Quick Notes

git cherry-pick <commit>: applies one specific commit's changes to the current branch as a new commit (new hash).
Multiple commits: git cherry-pick <hash1> <hash2> ... applies them in the listed order.
Conflicts: resolve then git cherry-pick --continue, or git cherry-pick --abort to cancel.
Most common use case: backporting a specific fix to another branch (e.g., an older release branch).

git cherry-pick: Key Takeaways

git cherry-pick provides surgical, single-commit precision for moving changes between branches, unlike the whole-branch scope of merge or rebase.
Backporting a fix to an older, still-supported branch is the most common and important real-world use case for cherry-pick.
Like a rebased commit, a cherry-picked commit is a genuinely new commit object with a new hash, even though its content and message match the original exactly.

Frequently Asked Questions About git cherry-pick

Q1. What does git cherry-pick do?

It takes the changes from one specific commit and applies them to your current branch, creating a new commit with the same content and message. It's a surgical way to move just one commit between branches, without bringing along anything else.

Q2. How is cherry-pick different from merging a branch?

Merging brings in all of a branch's unique commits at once. Cherry-pick applies exactly one commit you specify (or a listed sequence of them), leaving every other commit on that branch untouched and unaffected on your current branch.

Q3. What is a backport, and why is cherry-pick used for it?

A backport applies a fix from one branch (usually the primary development branch) back onto an older branch that still needs that fix but shouldn't receive unrelated ongoing changes. Cherry-picking just the specific fix commit accomplishes this precisely, without pulling in anything else.

Q4. How do I cherry-pick more than one commit at once?

List multiple commit hashes after the cherry-pick command, such as git cherry-pick a1b2c3d 9f8e7d6, and Git will apply them in that order, one after another.

Q5. What happens if a cherry-pick causes a conflict?

Resolve the conflict in the affected file exactly as you would during a merge or rebase, stage the resolved file, and run git cherry-pick --continue to proceed. If you decide to cancel entirely, git cherry-pick --abort safely backs out of the operation.

Summary

`git cherry-pick <commit>` applies the changes from one specific commit onto your current branch, creating a new commit with the same content and message but a new hash, since it's technically a new commit object with a different parent — leaving every other commit on the source branch completely untouched. Multiple commits can be cherry-picked in one operation by listing them, and conflicts are resolved using the same resolve-then-continue pattern as rebase, via `git cherry-pick --continue` or `--abort`. The most common and important real-world use case is backporting: applying a specific fix made on a primary development branch back onto an older, still-supported release branch, without pulling in that primary branch's other unrelated ongoing changes — a surgical, single-commit precision that neither merging nor rebasing an entire branch can provide.