git cherry-pick: How to Apply a Commit to Another Branch

git cherry-pick applies the changes from one specific commit to the current branch without merging the whole branch. Git computes the diff between the chosen commit and its parent, applies it on top of your HEAD and creates a new commit with the same message and author but a different hash, because its parent is different.

A typical scenario: you fixed a bug on a feature branch, and the fix is urgently needed on a release branch where the feature isn't ready yet. You can't merge the whole branch, but you can bring over a single commit.

How to cherry-pick a single commit into another branch

First find the hash of the commit you need, then switch to the branch it should go to, and run cherry-pick.

# 1. Find the commit on the feature branch
git log --oneline feature
a1b2c3d Fix division by zero in discount calculation
9f8e7d6 Add new checkout screen

# 2. Switch to the target branch
git switch release-1.4

# 3. Cherry-pick the commit
git cherry-pick a1b2c3d
[release-1.4 4e5f6a7] Fix division by zero in discount calculation
 Date: Mon Oct 5 14:12:03 2026 +0300
 1 file changed, 3 insertions(+), 1 deletion(-)

Note that the new commit got the hash 4e5f6a7, not a1b2c3d. They are two different objects with identical changes. The source branch feature is left untouched.

Instead of a hash you can pass any commit reference: git cherry-pick feature picks the latest commit on feature, git cherry-pick feature~2 picks the third one from the tip.

How to cherry-pick multiple commits

As a list

You can pass several hashes, and Git applies them in the given order, creating the same number of new commits.

git cherry-pick a1b2c3d 7c8d9e0 3f4a5b6

Order matters: if the second commit depends on the first and you list them the other way round, you'll get a conflict or broken code. It's safer to list them oldest to newest.

As a range

For consecutive commits, use range syntax. There's a trap here that trips up almost everyone: A..B means "commits reachable from B but not from A", so A itself is not included in the range.

# Picks the commits AFTER A up to and including B
git cherry-pick A..B

# Picks A and everything up to and including B
git cherry-pick A^..B

If you need everything that's on feature but not on main, git cherry-pick main..feature does the job. But if there are many commits, think twice: you may want a rebase or merge rather than cherry-pick.

Useful git cherry-pick flags

Why use -x

Six months from now someone will spot a fix on the release branch and wonder where it came from. The line added by -x answers that directly:

git cherry-pick -x a1b2c3d
git log -1
    Fix division by zero in discount calculation

    (cherry picked from commit a1b2c3d4e5f60718293a4b5c6d7e8f9012345678)

Use -x when the original commit is already published. When picking from your own local branch that you're going to delete, the reference would point nowhere, so you don't need the flag there.

Combine several commits into one: -n

git cherry-pick -n a1b2c3d 7c8d9e0
git status          # changes from both commits are staged
git commit -m "Discount calculation fixes"

Cherry-pick conflicts and how to resolve them

A conflict happens when the commit's changes don't fit the current code: the same lines already look different on the target branch. Git stops and tells you so.

git cherry-pick a1b2c3d
Auto-merging src/discount.js
CONFLICT (content): Merge conflict in src/discount.js
error: could not apply a1b2c3d... Fix division by zero in discount calculation
hint: After resolving the conflicts, mark them with
hint: "git add/rm <pathspec>", then run
hint: "git cherry-pick --continue".

From here you have three options:

1. Resolve and continue. Open the file, remove the <<<<<<<, ======= and >>>>>>> markers, keeping the correct version, then run git add src/discount.js and git cherry-pick --continue.
2. Skip the commit. When picking a list, git cherry-pick --skip skips the problematic commit and moves on to the next one.
3. Abort everything. git cherry-pick --abort returns the branch to its state before the operation started.

There's also git cherry-pick --quit: it stops the operation but keeps the commits already applied and the current state of the files. Handy when you've successfully picked half the list and want to handle the rest manually.

If the same conflicts keep coming back (say, you regularly port fixes to several release branches), enable git config rerere.enabled true. Git will remember how you resolved a conflict and reapply the resolution automatically next time.

How to cherry-pick a merge commit

A merge commit has two parents, and Git doesn't know which one to diff against. Without a hint you'll get an error:

git cherry-pick 5d6e7f8
error: commit 5d6e7f8 is a merge but no -m option was given.

The -m 1 flag says: compute the changes relative to the first parent, which is usually the branch that was merged into. That way you bring over everything the merged branch introduced as a single commit.

git cherry-pick -m 1 5d6e7f8

Keep in mind that Git won't consider the branch merged afterwards: on a future merge it may try to apply the same changes again.

git cherry-pick vs git apply

git apply often comes up alongside cherry-pick, since both "apply changes". But they work with different inputs.

Here's git apply in action when the commit isn't in your repository, for example a teammate sent you a diff as a file:

# Your teammate runs
git diff main..fix-discount > fix.patch

# You check and apply it
git apply --check fix.patch   # check whether the patch applies cleanly
git apply fix.patch           # apply to the working tree
git apply --3way fix.patch    # on mismatches, fall back to conflict markers

If you need to transfer a whole commit with its author and message, use git format-patch together with git am: the first saves commits to files, the second creates commits from them. It's essentially cherry-pick by email.

By the way, you can also cherry-pick from another repository: add it as a remote, run git fetch, and its commits become available by hash.

When cherry-pick is a bad idea

Cherry-pick creates duplicates: the same change lives in history under two hashes. In small doses that's fine, but in some scenarios it does more harm than good.

• Moving dozens of commits. If you're bringing over almost an entire branch, that's a job for rebase or merge. Cherry-pick here gives you a long trail of duplicates and more conflicts.
• Picking in both directions. A commit was picked from feature into main, and later feature gets merged into main. Git usually copes (the changes match), but if the lines were edited after the pick, you'll get a conflict out of nowhere.
• Dependent commits. The commit uses a function added two commits earlier. Cherry-pick brings over only the commit itself, and the code on the target branch won't build. Always check the build and tests after picking.

A good practice for hotfixes is to make the fix on the oldest supported branch first and merge it "upward" into newer ones. Then cherry-pick is needed only as an exception.

How to undo a cherry-pick

If the operation is still in progress (a conflict), run git cherry-pick --abort. If the commit is already created but not pushed, drop it:

git reset --hard HEAD~1

If the commit is already pushed to a shared branch, you can't rewrite history, so create a reverting commit:

git revert 4e5f6a7

And if you ran reset and changed your mind, the lost commit can be found via git reflog.

How to check whether a commit was already cherry-picked

Since the hashes differ, a plain git branch --contains won't help. Git can compare commits by the content of their changes (patch-id):

git cherry -v release-1.4 feature
- a1b2c3d Fix division by zero in discount calculation
+ 9f8e7d6 Add new checkout screen

A minus means an equivalent change is already on release-1.4, a plus means it isn't yet. An alternative is git log --cherry-pick --oneline release-1.4...feature, which hides twin commits. If you used -x, you can simply search the messages: git log --grep="cherry picked from commit a1b2c3d".

Summary

git cherry-pick is a precision tool: port a hotfix to a release, rescue a useful commit from an abandoned branch, or recover a commit made on the wrong branch. Remember three things: the new commit gets a new hash, the range A..B excludes A, and for public branches it's worth adding -x. If you need to apply a diff from a file rather than a commit, use git apply. Rebase, stash, cherry-pick and tags are covered hands-on in the Git course.