Git Cherry-Pick: Apply Specific Commits (Complete Guide)

The Problem Cherry-Pick Solves

Imagine your team works on a develop branch, and releases go out from main. A security patch is committed directly to develop because that is where the team works. Your release is tomorrow. You need that patch on main - but develop is weeks ahead with unfinished features you cannot ship yet.

Merging develop into main would bring in half-finished work. Reverting the other commits is dangerous. The answer is git cherry-pick: copy just that one commit's changes onto main, regardless of where it originally lived.

Other common scenarios where cherry-pick is the correct tool:

• Backporting a fix from main to a legacy support branch (v1.x, v2.x)
• Rescuing a commit from a branch that is about to be deleted or force-pushed
• Applying a commit from a colleague's unmerged feature branch to unblock your work
• Moving a commit you accidentally made on main to the correct feature branch

How Cherry-Pick Works Internally

Cherry-pick does not copy a commit verbatim. It replays the diff of the chosen commit on top of your current HEAD. Git computes what changed between the commit's parent and the commit itself, then applies that patch to the current branch. The result is a new commit with a different SHA but identical changes.

This is an important distinction: the cherry-picked commit has a new identity. If the same commit later gets merged via a regular merge, Git may see it as a duplicate change and handle it gracefully - or it may create a conflict if history has diverged significantly.

Basic Syntax

# Apply a single commit to the current branch
git cherry-pick abc1234

# Apply multiple specific commits (applied in order)
git cherry-pick abc1234 def5678 ghi9012

# Apply an inclusive range of commits
git cherry-pick abc1234^..def5678

# Apply a range (exclusive of start commit)
git cherry-pick abc1234..def5678

The caret (^) suffix on the start commit is easy to miss. Without it, abc1234..def5678 excludes abc1234 itself. With it, abc1234^..def5678 includes abc1234. Use git log first to confirm the range before running the pick.

Step-by-Step: Cherry-Pick a Hotfix to Main

Here is a real workflow. You have a develop branch and need commit f3a9b2c (a security fix) on main.

1. Find the commit hash. On develop, run git log --oneline and note the short SHA of the fix commit.
2. Switch to the target branch.

git checkout main
git pull origin main   # always start from a clean, up-to-date state

3. Run the cherry-pick.

git cherry-pick f3a9b2c

4. Verify the result.

git log --oneline -5   # confirm the new commit is at HEAD
git show HEAD          # review the diff

5. Push to remote.

git push origin main

Handling Conflicts

When the cherry-picked diff touches lines that have changed differently on the target branch, Git cannot auto-apply it and stops with a conflict. The process is similar to resolving a merge conflict:

# Git stops and tells you there is a conflict
# Edit the conflicting file(s) to resolve
git add path/to/resolved-file.js

# Continue the cherry-pick
git cherry-pick --continue

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

After resolving conflicts and staging the files, git cherry-pick --continue opens your editor to confirm the commit message, then completes the operation. Use --abort if you decide the conflict is too complex and want to start over.

If you hit frequent conflicts cherry-picking between branches with very different histories, consider whether a merge or rebase is more appropriate for your situation. Cherry-pick shines for targeted, isolated commits - not for wholesale branch synchronisation.

Useful Flags

Cherry-pick has several flags that are useful in specific situations:

• -n / --no-commit: Applies the changes to the working tree and index without creating a commit. Useful when you want to combine multiple cherry-picks into a single commit or inspect changes before committing.
• -x: Appends a line to the commit message noting the original commit SHA (cherry picked from commit abc1234). Highly recommended when backporting - it creates a clear audit trail.
• -e / --edit: Opens the editor to modify the commit message before completing the pick.
• -s / --signoff: Appends a Signed-off-by trailer using your Git identity, useful for projects that require sign-off on every commit.
• --strategy-option ours / theirs: Resolves all conflicts automatically using either the current branch's version or the cherry-picked version. Use carefully.

# Backport with audit trail
git cherry-pick -x f3a9b2c

# Stage changes only, don't commit yet
git cherry-pick -n f3a9b2c f4b1d3e
# ... inspect, then:
git commit -m "Backport: security fix for CVE-2026-1234"

Cherry-Picking a Range (Multiple Commits)

When backporting a feature that spans several commits, pick the entire range rather than each commit individually:

# Get the range from the log
git log --oneline develop | head -20

# Example output:
# a1b2c3d  Fix null pointer in payment processor
# e4f5g6h  Add retry logic for failed payments
# i7j8k9l  Extract payment service class

# Cherry-pick all three in order (oldest first)
git cherry-pick i7j8k9l^..a1b2c3d

Git applies commits from oldest to newest within the range. If any commit in the range conflicts, the process pauses at that commit. Resolve it and --continue. You may need to repeat this for each conflicting commit in the range.

When NOT to Use Cherry-Pick

Cherry-pick is powerful but has genuine downsides that make other strategies preferable in some cases:

• Duplicate commits in history: After a cherry-pick, the same logical change exists as two different commits with different SHAs. If the original branch is ever merged back, Git may apply the change twice or create confusion in git log.
• Dependent commits: If the commit you want to cherry-pick depends on changes introduced by earlier commits that are not on the target branch, the pick will conflict or produce broken code even if it applies cleanly.
• Replacing a regular merge: If you find yourself cherry-picking many commits to keep two branches in sync, you probably want a merge or rebase instead. Cherry-pick is for surgical, targeted moves - not branch synchronisation.

As a rule: use cherry-pick for one or a few well-understood commits. Use merge or rebase for bringing branches into alignment.

Cherry-Pick in CI / Automation

In automated release pipelines, cherry-pick operations appear frequently for backporting fixes to release branches. A common pattern:

#!/bin/bash
# Backport a commit to all active release branches
COMMIT="$1"
BRANCHES=("release/v2.x" "release/v3.x")

for branch in "${BRANCHES[@]}"; do
  git checkout "$branch"
  git pull origin "$branch"
  git cherry-pick -x "$COMMIT" || {
    echo "Conflict on $branch - manual resolution required"
    git cherry-pick --abort
  }
  git push origin "$branch"
done

The -x flag is especially valuable here: every backported commit on every release branch will reference the original SHA, making it easy to trace the origin during audits.

FAQ

Does cherry-pick change the original commit?

No. Cherry-pick creates a new commit on the target branch. The original commit on its original branch is completely unaffected. You end up with two commits that contain the same changes but have different SHAs, timestamps, and parent commits.

Can I cherry-pick from a remote branch without checking it out?

Yes. First fetch the remote: git fetch origin feature/my-branch. Then use the remote ref directly: git cherry-pick origin/feature/my-branch~2 picks the commit two steps back from the tip of that remote branch. You can also use the full SHA obtained from git log origin/feature/my-branch.

What is the difference between cherry-pick and patch / apply?

git cherry-pick works directly with commit objects in your local repository - no file export required. git format-patch + git am exports commits to .patch files and applies them, which is useful for sending patches over email or applying commits from a repository you cannot directly access. For most day-to-day use, cherry-pick is simpler.

Why does git cherry-pick create a different SHA than the original?

A Git commit SHA is a hash of the commit's content, its parent SHA, author, timestamp, and message. The cherry-picked commit has a different parent (your current branch's HEAD) and a different timestamp, so it necessarily gets a different SHA - even though the file changes are identical.

Can cherry-pick be undone?

Yes. If you have not pushed: git reset --hard HEAD~1 removes the cherry-picked commit from your branch. If you have already pushed, use git revert HEAD to create a new commit that undoes the change - this is safer than force-pushing in a shared repository.

What happens if I cherry-pick a merge commit?

By default, cherry-picking a merge commit fails because Git does not know which parent to diff against. You must specify the mainline parent with -m 1 (for the first parent): git cherry-pick -m 1 abc1234. The number corresponds to which parent branch you consider the "main" line. Use git show abc1234 to see the parent list.

Use our free tool here → Diff Checker to visually compare what a cherry-pick will change before you run it.