Git Cherry-Pick: The Complete Guide for 2026

Published February 12, 2026 · 22 min read

Cherry-pick is the surgical tool in Git's arsenal. While merge and rebase operate on entire branches, cherry-pick lets you reach into any branch, grab a specific commit, and apply it exactly where you need it. It is the command you reach for when a critical bugfix landed on main but your release branch needs it now, or when a colleague built one useful function inside a feature branch you are not ready to merge.

This guide covers everything: basic cherry-picking, ranges, merge commits, conflict resolution, the tradeoffs versus merge and rebase, and the real-world workflows where cherry-pick is the right tool. Every example is practical and copy-pasteable.

Table of Contents

• What Is Git Cherry-Pick?
• Basic Cherry-Pick Usage
• Cherry-Picking a Range of Commits
• Cherry-Pick Without Committing
• Cherry-Picking Merge Commits
• Handling Cherry-Pick Conflicts
• Cherry-Pick vs Merge vs Rebase
• When to Use Cherry-Pick
• Common Mistakes and Pitfalls
• Real-World Cherry-Pick Workflows
• FAQ

What Is Git Cherry-Pick?

git cherry-pick takes a commit from anywhere in your repository and replays it on top of your current branch. It creates a new commit with the same diff and the same message, but a different hash (because the parent commit is different).

Visually, here is what happens. You have two branches and you want commit F from feature on main:

Before cherry-pick:

          D---E---F---G  feature
         /
    A---B---C  main (HEAD)

git cherry-pick F

After cherry-pick:

          D---E---F---G  feature
         /
    A---B---C---F'  main (HEAD)

Commit F' has the same code changes as F, but it is a completely independent commit. It has a different hash and a different parent (C instead of E). The original commit F on the feature branch is untouched.

Internally, Git computes the diff that commit F introduced (the difference between E and F), then applies that diff to your current HEAD (C). If the diff applies cleanly, Git creates the new commit automatically. If not, you get a conflict to resolve.

This is fundamentally different from merge, which integrates entire branch histories, and rebase, which replays a sequence of commits onto a new base. Cherry-pick is a scalpel; merge and rebase are broader instruments.

Basic Cherry-Pick Usage

The simplest form takes a single commit hash:

# Switch to the branch where you want the commit
git checkout main

# Cherry-pick a specific commit by its hash
git cherry-pick a1b2c3d

Git applies the changes from a1b2c3d and creates a new commit on main with the same message. Done.

Finding the Commit Hash

You need the commit hash before you can cherry-pick. Here are the most common ways to find it:

# View the log of another branch
git log --oneline feature/payments
# Output:
# f7e6d5c Add refund processing
# a1b2c3d Fix payment amount calculation
# 9k8j7i6 Add Stripe webhook handler

# View the log with the full diff to confirm the right commit
git log -p feature/payments -3

# Search by commit message
git log --oneline --all --grep="payment amount"

Cherry-Pick with the -x Flag

The -x flag appends a line to the commit message noting where the commit was cherry-picked from. This is essential for traceability in team workflows:

git cherry-pick -x a1b2c3d

# The resulting commit message:
# Fix payment amount calculation
#
# (cherry picked from commit a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0)

Always use -x in shared repositories. When someone reads the log months later, they can trace exactly where the commit came from.

Cherry-Picking Multiple Individual Commits

# Cherry-pick three specific commits in order
git cherry-pick a1b2c3d e4f5g6h i7j8k9l

# They are applied in the order listed, left to right
# Each becomes its own commit on the current branch

If any commit in the sequence causes a conflict, Git stops and waits for you to resolve it before continuing with the remaining commits.

Cherry-Picking a Range of Commits

When you need more than one commit from a branch, you can cherry-pick a range using the double-dot notation:

# Cherry-pick all commits AFTER A up to and INCLUDING B
git cherry-pick A..B

The critical detail: commit A is excluded. The range A..B means "everything after A, up to B." If you want to include A as well, use the caret syntax:

# Include commit A (start from A's parent)
git cherry-pick A^..B

Practical Example

Suppose the feature branch has these commits and you want the last three:

git log --oneline feature/auth
# c3c3c3c Add password reset endpoint
# b2b2b2b Add email verification
# a1a1a1a Add login rate limiting
# 9z9z9z9 Refactor auth middleware
# 8y8y8y8 Initial auth setup

# Cherry-pick the last 3 commits (after 9z9z9z9, up to c3c3c3c)
git cherry-pick 9z9z9z9..c3c3c3c

# Or equivalently, include a1a1a1a explicitly:
git cherry-pick a1a1a1a^..c3c3c3c

Both commands produce three new commits on your current branch: A1', B2', and C3', preserving the original order.

Using Branch Names with Ranges

# Cherry-pick the last 4 commits from a branch
git cherry-pick feature/auth~4..feature/auth

# Cherry-pick everything since a branch diverged from main
git cherry-pick main..feature/auth

Cherry-Pick Without Committing

The -n (or --no-commit) flag applies the changes to your working tree and staging area but does not create a commit. This is useful when you want to combine multiple cherry-picks into a single commit or modify the changes before committing:

# Apply changes without committing
git cherry-pick -n a1b2c3d

# Check what was applied
git status
git diff --staged

# Modify if needed, then commit manually
git commit -m "Backport: fix payment calculation from feature branch"

Combining Multiple Commits into One

# Cherry-pick three commits without committing any of them
git cherry-pick -n a1b2c3d
git cherry-pick -n e4f5g6h
git cherry-pick -n i7j8k9l

# All three diffs are now staged. Commit as one:
git commit -m "Backport payment fixes from feature/payments"

This is cleaner than cherry-picking three commits and then squashing them with interactive rebase. Use it when you know upfront that the commits belong together on the target branch.

Cherry-Pick and Edit

Use -e (or --edit) to open the editor so you can modify the commit message before it is created:

# Cherry-pick and edit the message
git cherry-pick -e a1b2c3d

Cherry-Picking Merge Commits

Merge commits are special: they have two parents. When you try to cherry-pick one, Git does not know which parent to diff against, so it fails:

git cherry-pick m1m1m1m
# error: commit m1m1m1m is a merge but no -m option was given

You must tell Git which parent to use with the -m flag. Parent 1 is the branch that was merged into (usually main), and parent 2 is the branch that was merged (the feature branch):

# Use parent 1 (the mainline) — this gives you the feature's changes
git cherry-pick -m 1 m1m1m1m

# Use parent 2 — this gives you the mainline's changes (rarely what you want)
git cherry-pick -m 2 m1m1m1m

In almost every case, you want -m 1. This tells Git: "diff the merge commit against its first parent and apply that diff." The result is the same set of changes that the merged branch introduced.

How to Identify Parents

# Show a merge commit's parents
git show --format="%P" m1m1m1m
# Output: abc1234 def5678
# abc1234 = parent 1 (mainline)
# def5678 = parent 2 (merged branch)

# Or use a more readable format
git log -1 --format="%H %P %s" m1m1m1m

When to Avoid Cherry-Picking Merges

Cherry-picking a merge commit applies all the changes from the merged branch as a single flat diff. You lose the individual commit history. If the merge brought in 20 commits, you get one commit with all 20 diffs squashed together. Often it is better to cherry-pick the individual commits from the source branch instead.

Handling Cherry-Pick Conflicts

Conflicts happen when the diff from the cherry-picked commit cannot be applied cleanly to your current branch. The surrounding code has changed, or the same lines were modified differently.

git cherry-pick a1b2c3d
# CONFLICT (content): Merge conflict in src/utils/payment.ts
# error: could not apply a1b2c3d... Fix payment amount calculation
# hint: After resolving the conflicts, mark the corrected paths
# hint: with 'git add ' and run 'git cherry-pick --continue'

Step 1: See which files have conflicts:

git status
# Unmerged paths:
#   both modified:   src/utils/payment.ts

Step 2: Open the file and resolve the conflict markers:

<<<<<<< HEAD
const total = subtotal * (1 + taxRate);
=======
const total = Math.round(subtotal * (1 + taxRate) * 100) / 100;
>>>>>>> a1b2c3d (Fix payment amount calculation)

The section between <<<<<<< HEAD and ======= is your current branch's code. The section between ======= and >>>>>>> is from the cherry-picked commit. Edit the file to produce the correct result:

const total = Math.round(subtotal * (1 + taxRate) * 100) / 100;

Step 3: Stage the resolved file and continue:

git add src/utils/payment.ts
git cherry-pick --continue

Cherry-Pick Escape Hatches

# Abort the cherry-pick and return to the pre-cherry-pick state
git cherry-pick --abort

# Skip the current commit and continue with remaining commits
# (when cherry-picking a range or multiple commits)
git cherry-pick --skip

Use --abort freely. There is no cost to aborting, investigating the conflict, and trying again.

Using a Merge Tool

# Launch your configured merge tool for conflict resolution
git mergetool

# Or resolve with a specific strategy — keep their version
git checkout --theirs src/utils/payment.ts
git add src/utils/payment.ts
git cherry-pick --continue

# Or keep your version
git checkout --ours src/utils/payment.ts
git add src/utils/payment.ts
git cherry-pick --continue

Cherry-Pick vs Merge vs Rebase

All three commands move changes between branches, but they work differently and serve different purposes:

Key insight: Cherry-pick is the only one of the three that does not establish any relationship between the source and destination branches. Git has no record that the cherry-picked commit came from somewhere else (unless you use -x). This makes it ideal for one-off transfers but problematic for ongoing integration.

For a deep dive into rebase, see our Git Rebase Complete Guide.

When to Use Cherry-Pick

1. Hotfixes to Production

The most common and most justified use of cherry-pick. A bug is found in production, fixed on main, and needs to be applied to the release branch immediately:

# Fix lands on main
git checkout main
git log --oneline -1
# f1x2b3g Fix null pointer in user session handler

# Apply to the release branch
git checkout release/v2.8
git cherry-pick -x f1x2b3g
git push origin release/v2.8

2. Backporting to Older Versions

When you maintain multiple release versions, cherry-pick lets you move fixes backward without merging unrelated features:

# Security fix committed on main
# Backport to v2.7, v2.6, and v2.5

git checkout release/v2.7
git cherry-pick -x f1x2b3g

git checkout release/v2.6
git cherry-pick -x f1x2b3g

git checkout release/v2.5
git cherry-pick -x f1x2b3g

3. Pulling a Specific Feature from a Long-Running Branch

A colleague's feature branch has been open for weeks. One of their commits adds a utility function you need now, but you are not ready to merge the whole branch:

# Find the commit you need
git log --oneline feature/big-refactor --grep="date parser"
# 5u6t7i8 Add ISO 8601 date parser utility

# Grab just that commit
git cherry-pick 5u6t7i8

4. Recovering Lost Commits

If a branch was deleted or a reset went wrong, cherry-pick can rescue individual commits from the reflog:

# Find the lost commit in the reflog
git reflog --all | grep "important feature"
# abc1234 HEAD@{15}: commit: Add important feature

# Cherry-pick it onto your current branch
git cherry-pick abc1234

5. Splitting a Branch After the Fact

You built three unrelated features on a single branch. Your team wants them reviewed separately. Cherry-pick each group onto its own branch:

git checkout main

git checkout -b feature/auth-improvements
git cherry-pick a1a1a1a b2b2b2b  # auth commits

git checkout main
git checkout -b feature/api-rate-limiting
git cherry-pick c3c3c3c d4d4d4d  # rate limiting commits

git checkout main
git checkout -b feature/logging-upgrade
git cherry-pick e5e5e5e  # logging commit

Common Mistakes and Pitfalls

Mistake 1: Cherry-Picking Instead of Merging

Problem: You cherry-pick every commit from a feature branch instead of merging it. You now have duplicate commits, and when someone eventually merges the source branch, the same changes exist twice.

Fix: If you need the entire branch, use merge. Cherry-pick is for individual commits. If you have already cherry-picked and now need to merge, Git usually handles the duplicates gracefully, but the log is cluttered.

Mistake 2: Forgetting the -x Flag

Problem: You cherry-pick a hotfix to three release branches. Six months later, nobody knows where those commits came from or whether all branches received the fix.

Fix: Always use git cherry-pick -x in shared repositories. The appended line creates a paper trail.

Mistake 3: Cherry-Picking Commits That Depend on Earlier Work

Problem: Commit C adds a function that calls a helper introduced in commit B. You cherry-pick C without B, and the code breaks.

Fix: Before cherry-picking, read the diff carefully. If the commit references code that does not exist on your branch, cherry-pick the prerequisite commits first. Use git log --oneline --follow -- path/to/file to trace a file's history and find dependencies.

# Check what a commit actually changes before cherry-picking
git show a1b2c3d --stat   # file list
git show a1b2c3d          # full diff

Mistake 4: Cherry-Picking a Merge Commit Without -m

Problem: You run git cherry-pick <merge-hash> and get an error about missing the -m option.

Fix: Use -m 1 for merge commits. See the merge commits section above for details.

Mistake 5: Cherry-Picking in the Wrong Direction

Problem: You cherry-pick a commit from main to your feature branch, then later merge your feature branch back into main. The commit now appears twice in the history.

Fix: Cherry-pick in one direction only. The typical pattern is: commit to main (or the primary development branch), then cherry-pick to release branches. Avoid cherry-picking from main to feature branches; use rebase or merge instead to keep your feature branch updated.

Mistake 6: Not Testing After Cherry-Pick

Problem: The cherry-pick applies cleanly but the code does not work because the surrounding context is different on the target branch.

Fix: Always build and run tests after cherry-picking. A clean apply does not mean correct behavior. The commit might depend on configuration, environment variables, or other code that differs between branches.

Real-World Cherry-Pick Workflows

Workflow 1: Hotfix Pipeline

The most battle-tested cherry-pick workflow. A bug is discovered in production, fixed, and distributed to all active release branches:

# 1. Create a hotfix branch from the release tag
git checkout -b hotfix/session-crash v2.8.3

# 2. Fix the bug
vim src/session/handler.ts
git add src/session/handler.ts
git commit -m "Fix crash when session token is expired"

# 3. Merge the fix into main
git checkout main
git merge hotfix/session-crash

# 4. Cherry-pick the fix to the current release branch
git checkout release/v2.8
git cherry-pick -x HEAD  # HEAD is the merge on main

# 5. Cherry-pick to older supported releases
git checkout release/v2.7
git cherry-pick -x <hash-of-fix-commit>

# 6. Tag the patched releases
git checkout release/v2.8
git tag v2.8.4
git checkout release/v2.7
git tag v2.7.9

Workflow 2: Release Branch Backporting

When your team uses long-lived release branches, cherry-pick keeps them maintained without merging unfinished features:

# Weekly process: cherry-pick eligible fixes to release branches
# Use a label or tag to mark commits as "backport-worthy"

# Find commits tagged for backporting
git log --oneline main --grep="[backport]"
# a1b2c3d [backport] Fix memory leak in connection pool
# e4f5g6h [backport] Update TLS certificate validation

# Apply them to the release branch
git checkout release/v3.0
git cherry-pick -x a1b2c3d e4f5g6h

Workflow 3: Cross-Team Collaboration

Team A built a utility that Team B needs, but Team A's branch is not ready for merge:

# Team B finds the commit they need
git fetch origin
git log --oneline origin/feature/team-a-platform \
    --grep="HTTP retry"
# 7x8y9z0 Add HTTP client with exponential backoff retry

# Team B cherry-picks it
git checkout feature/team-b-dashboard
git cherry-pick -x 7x8y9z0

Workflow 4: Reverting a Cherry-Pick

If a cherry-picked commit causes problems, revert it the same way you would revert any commit:

# Find the cherry-picked commit on the current branch
git log --oneline -5
# f1f1f1f Fix payment calculation (cherry picked from commit a1b2c3d)
# ...

# Revert it
git revert f1f1f1f

# The revert creates a new commit that undoes the cherry-pick
# The original commit on the source branch is unaffected

Workflow 5: Using Cherry-Pick with CI/CD

Automate cherry-picks in your CI pipeline for systematic backporting:

#!/bin/bash
# backport.sh — Cherry-pick a commit to multiple release branches

COMMIT=$1
BRANCHES="release/v3.0 release/v2.9 release/v2.8"

for branch in $BRANCHES; do
    echo "Backporting $COMMIT to $branch"
    git checkout "$branch"
    git pull origin "$branch"

    if git cherry-pick -x "$COMMIT"; then
        git push origin "$branch"
        echo "Success: $branch"
    else
        git cherry-pick --abort
        echo "CONFLICT: $branch — manual resolution needed"
    fi
done

git checkout main

Frequently Asked Questions

Continue Learning

This guide is part of our Git deep-dive series. Explore the related guides to build a complete understanding of Git workflows:

• Git Rebase: The Complete Guide — Interactive rebase, squash, autosquash, and recovery
• Git Branching Strategies Guide — Git Flow, GitHub Flow, and Trunk-Based Development
• Git Merge Conflicts Guide — Resolving conflicts systematically
• Git Cheat Sheet — One-page quick reference for all Git commands