Git cherry-pick

git cherry-pick applies the change from a specific commit on another branch to the branch you’re on. It doesn’t merge the commit history or the whole branch; it just moves the change you picked as a new commit.

In short: the moment you say “let this fix on feature/payment land on release right away too,” the right tool is usually cherry-pick.

What problem does it solve?

merge moves an entire branch’s history, and rebase moves the base of the commits. Sometimes both of these are more than you need: what you need is just a single fix, security patch, or independent improvement.

Example situation:

main:             A --- B --- C
                           \
feature/search:            D --- E --- F
                              ^
                         critical bug fix

Merging the feature/search branch into main would also bring along E and F — work that isn’t ready yet. Instead, you can pick just commit D:

main:             A --- B --- C --- D'
feature/search:            D --- E --- F

D' contains the same change as D, but since it was created on top of main, it has a different commit hash.

When should it be used?

• When you need to bring a single bug fix from a development branch into a release or hotfix branch.
• When there’s an independent improvement needed across multiple branches.
• When safely moving a commit that was pushed to the wrong branch, into the target branch.
• When you want to take a specific, already-reviewed commit from a PR, not the whole PR.

It’s especially valuable in production hotfix flows: instead of a large, risky merge, you take the one change with a clear, narrow scope.

When should it NOT be used?

If you want most or all of the commits from a feature branch, merge or, if it fits the team’s workflow, rebase is clearer. Continually cherry-picking the same commits into different branches can also be a sign that the branches have drifted apart from each other.

Another risk: if the commit being moved is already indirectly present in the target branch, reapplying the same change can produce conflicts or duplicated code. Check first whether the change already exists.

Basic usage

First, find the commit hash:

git log --oneline feature/search
# a1b2c3d Fix: crash on empty search result

Switch to the branch the change should go to and apply the commit:

git switch main
git pull --ff-only origin main
git cherry-pick a1b2c3d

If successful, Git creates a new commit on the active branch. To verify:

git log --oneline -3
git show --stat HEAD

git pull --ff-only isn’t mandatory, but it ensures you’re working from an up-to-date base on a shared branch and avoids unexpected merge commits.

Example: Moving a hotfix to the release branch

Suppose the following commit was made on the develop branch for a critical bug in the payment screen:

7f3e91a fix(payment): show retry option to user on timeout

Take just this fix into the release branch:

git switch release/2.4
git cherry-pick -x 7f3e91a
git push origin release/2.4

The -x here adds the source commit info to the new commit message:

(cherry picked from commit 7f3e91a...)

Using -x on shared release and maintenance branches is a good traceability habit. It later makes it easy to see where a change came from.

Moving multiple commits

You can pick commits one by one in dependency order:

git cherry-pick 12ab34c 56de78f 90ab12c

For a consecutive commit range:

git cherry-pick 12ab34c^..90ab12c

This expression includes the first commit too. Without the ^ marker, the starting commit is excluded from the range — a small mistake that’s made often.

If a conflict occurs

If the same lines have changed differently in the target branch, Git can’t decide automatically and the cherry-pick stops.

git cherry-pick a1b2c3d
# CONFLICT (content): Merge conflict in src/services/search.ts

Flow to follow:

git status
# Edit the conflicting files; remove the <<<<<<<, ======= and >>>>>>> markers.
git add src/services/search.ts
git cherry-pick --continue

If you want to give up on taking the change, revert the working tree to its state before the cherry-pick:

git cherry-pick --abort

If Git says after resolution that the change is redundant or already applied, you can skip that commit:

git cherry-pick --skip

--skip should only be used when you’re sure the change is genuinely already present in the target branch or is no longer needed.

Reviewing before committing

Apply the change to the working area, test it, and write the commit message yourself:

git cherry-pick --no-commit a1b2c3d
npm test
git commit -m "fix(search): handle empty result case"

The short form is -n. This method is useful when you need to combine a few small commits into a single release fix commit, or make small adaptations specific to the target branch.

Safe workflow checklist

• Verify you’re on the target branch with git branch --show-current.
• Read the source commit first with git show <hash>; make sure there are no side effects you’re not bringing along.
• If the commit depends on other commits, take those dependencies too, in the right order.
• Check the tests and the git diff HEAD^ HEAD output after applying.
• If moving to a shared branch, use -x and review the result before pushing.

Quick command reference

Purpose	Command
Apply a single commit	git cherry-pick <commit>
Add source to commit message	git cherry-pick -x <commit>
Apply without creating a commit	git cherry-pick -n <commit>
Continue after resolving a conflict	git cherry-pick --continue
Undo the operation	git cherry-pick --abort
Skip the current commit	git cherry-pick --skip

Cherry-pick isn’t a copy-paste trick — it’s a controlled tool for moving changes. When used on small-scope, clearly justified, tested commits, it speeds up hotfix and release workflows while keeping the main branch from being polluted with unnecessary changes.