Cherry-picking commits in Git

Most of the time you move work between branches with merge or rebase — bring the whole branch over and let Git figure out what changed. But occasionally you only want one specific commit. A hotfix landed on main and you need it on the release branch. A bug fix is buried inside a half-finished feature branch and you want only that fix shipped today. That's what git cherry-pick is for.

This tutorial covers the basic command, the options worth knowing, what happens when conflicts come up, and when you should reach for merge or rebase instead.

What git cherry-pick does

git cherry-pick takes the changes introduced by a specific commit and replays them as a new commit on your current branch. The new commit has the same author and message as the original, but a different hash — because it has a different parent.

A short timeline makes it clearer. Say you have two branches:

main:    A — B — C — D
                 \
release: A — B — E

If commit D on main is a critical bug fix, you can apply just D to release without merging the rest of main:

git switch release
git cherry-pick D

After the cherry-pick:

main:    A — B — C — D
                 \
release: A — B — E — D'

D' is a new commit with the same changes as D but a different hash. The release branch now has the bug fix without dragging in C.

Basic usage

Cherry-picking a single commit takes the commit hash. You can find it with git log:

git log --oneline main

4f1c2a8 Fix race condition in payment processor
8fd3350 Add the correct link to Brie
5eba8ab Remove Cheddar
d240853 Initial commit

Switch to the branch where you want the commit applied, then cherry-pick:

git switch release
git cherry-pick 4f1c2a8

Git applies the changes and creates a new commit. The output confirms what happened:

[release 9a3b71c] Fix race condition in payment processor
 Date: Fri May 23 11:24:01 2026 +0100
 1 file changed, 4 insertions(+), 2 deletions(-)

Push the branch and the fix is live wherever release is deployed.

Cherry-picking multiple commits

You can list several hashes in one command, and Git applies them in order:

git cherry-pick 4f1c2a8 8fd3350

If any one of them conflicts or fails, the operation stops and you handle the failed commit before continuing — more on that below.

Cherry-picking a range of commits

For a contiguous range, use the A..B syntax (which is exclusive of A):

git cherry-pick main~5..main~2

That picks the four commits between main~5 (excluded) and main~2 (included). If you want both endpoints included, use A^..B:

git cherry-pick main~5^..main~2

Note: A long cherry-pick range is usually a signal that you should be merging or rebasing instead. The cost of cherry-picking many commits is that you end up with two copies of the same changes (the originals and the picks), which makes future merges of the source branch noisier than necessary.

Useful flags

A few options come up often enough to be worth remembering.

-x — record the source commit

-x appends (cherry picked from commit <hash>) to the new commit message. It's invaluable when you're cherry-picking between long-lived branches because it tells anyone reading the log exactly where the change came from:

git cherry-pick -x 4f1c2a8

The resulting commit message looks like:

Fix race condition in payment processor

(cherry picked from commit 4f1c2a8b6e9f3d2c1a8b6e9f3d2c1a8b6e9f3d2c)

The convention is to always use -x when cherry-picking onto public branches, and skip it for local-only workflow shuffling.

--no-commit (or -n) — apply without committing

--no-commit stages the changes but doesn't create a commit, so you can adjust the result before recording it:

git cherry-pick --no-commit 4f1c2a8
# edit files, change tests, etc.
git commit -m "Fix race condition in payment processor (backported)"

Useful when you want to combine several cherry-picks into a single commit, or when the original commit's message doesn't fit the destination branch's conventions.

--edit (or -e) — edit the message during the pick

Most of the time you'll want the original message verbatim. When you don't:

git cherry-pick --edit 4f1c2a8

Git opens your editor with the message prefilled, ready to be rewritten before the commit is created.

-m — cherry-pick a merge commit

Merge commits have two parents, so Git needs to know which side of the merge you want to apply. -m 1 keeps the first parent (the branch you were merging into):

git cherry-pick -m 1 <merge-hash>

This is the same -m flag used by git revert for merges — same logic, opposite intent.

Resolving conflicts during a cherry-pick

If the commit you're picking touches code that has diverged on the destination branch, Git stops and asks you to resolve the conflict manually. The output looks like a normal merge conflict:

error: could not apply 4f1c2a8... Fix race condition in payment processor
hint: After resolving the conflicts, mark them with
hint: "git add/rm <conflicted_files>", then run
hint: "git cherry-pick --continue".

Open the conflicted files, look for the <<<<<<< HEAD / ======= / >>>>>>> markers, decide what the correct merged content is, then save. Stage the resolved files:

git add path/to/conflicted-file

And finish the pick:

git cherry-pick --continue

Git opens the editor with the commit message — save to confirm.

Aborting or skipping

If the conflict is too tangled to resolve, abort and go back to where you started:

git cherry-pick --abort

When you're cherry-picking a list of commits and one in the middle is no longer relevant, skip it:

git cherry-pick --skip

Git moves on to the next commit in the queue.

When not to cherry-pick

Cherry-pick is a precision tool, not a workflow. A few situations where it's the wrong choice:

• Moving a long sequence of related commits. Use git rebase --onto instead — it preserves the relationship between commits and avoids creating duplicate history.
• Bringing in a feature branch. Use git merge. Cherry-picking the commits one by one duplicates them in history and complicates a future merge of the branch itself.
• Synchronising two long-lived branches. A scheduled merge between them is almost always cleaner than ad-hoc picks, because Git tracks what's already merged and won't re-apply it.

A reliable rule of thumb: if you're cherry-picking more than two or three commits at once, ask whether merge or rebase would do the job more honestly. The point of git cherry-pick is to lift one specific change out of context — when the context matters, use a tool that preserves it.

Practical recipes

"A hotfix landed on main and I need it on the release branch right now" — git switch release && git cherry-pick -x <hotfix-hash> && git push.

"I want to pick the fix but ditch the unrelated formatting changes that came with it" — git cherry-pick --no-commit <hash>, unstage the parts you don't want with git restore --staged, then commit.

"The cherry-pick conflicted and I'm stuck" — git cherry-pick --abort to go back to where you started. Then look at whether git rebase --onto or a partial merge would handle it better.

"I cherry-picked a commit and now the message says nothing about where it came from" — Next time, use -x. For commits already made, git commit --amend lets you edit the message after the fact.

"I picked a merge commit and Git complained about multiple parents" — Use -m 1 to tell Git to take the first-parent side of the merge.

These workflows are the same against GitHub, GitLab, and Bitbucket — cherry-pick is a local operation, and git push is what sends the new commit to the remote.

Quick reference

Next steps

• Reverting and undoing commits — the inverse: removing a commit you already applied
• Branching and merging — when a merge or rebase would beat a cherry-pick
• Viewing the commit history — find the hash you want to pick

A cherry-pick is how a hotfix gets onto a release branch. DeployHQ can watch that release branch and deploy the picked commit the moment it lands — so a critical fix moves from main to production in a single workflow, with one-click rollback waiting if anything goes wrong. Start deploying free.