☕ Buy a Coffee
Home / Productivity & Coding

How to Use Git 'Cherry-Pick' to Move One Commit

Selectively apply specific bug fixes or features from a development branch into production without merging the entire history.

Sachin Siju
Sachin Siju
Lead Systems Engineer & Tech Blogger
Jul 01, 2026 4 min read
How to Use Git 'Cherry-Pick' to Move One Commit

When You Need One Commit, Not a Whole Merge

Merging or rebasing brings an entire branch's history along with it. Sometimes that is not what you want — a critical bug fix landed on develop and needs to go straight to production, but the rest of develop is half-finished feature work you are not ready to ship. git cherry-pick takes the changes introduced by a single existing commit and replays them as a brand new commit on your current branch, leaving everything else untouched.

Finding the Commit You Want

First, identify the commit hash. Check out the branch that has the commit, or just look it up with git log:

git log --oneline develop

This prints a compact list of commits with their short hashes:

a3f9c21 Fix null pointer in payment retry logic
7b2d114 WIP: new checkout flow
c88e0aa Add experimental discount engine

Say you only want a3f9c21, the bug fix, applied to production — not the other two.

Applying the Commit

Switch to the branch that should receive the fix, then cherry-pick the commit by its hash:

git checkout production
git cherry-pick a3f9c21

Git creates a new commit on production containing the exact same diff as a3f9c21, with a new commit hash (since it now has a different parent) but the original commit message preserved. Push it like any normal commit:

git push origin production

Cherry-Picking Multiple Commits

You can pick several commits in one go by listing them in order:

git cherry-pick a3f9c21 d4e7f02 9c1b3aa

Or grab a contiguous range with two dots. Note that the range is exclusive of the first hash and inclusive of the last, so include the commit just before the one you actually want first:

git cherry-pick 7b2d114..a3f9c21

Handling Merge Conflicts

If the target branch has diverged from where the commit originated, Git may not be able to apply the patch cleanly. It will pause and mark the conflicting files just like a merge:

git status

Open the flagged files, resolve the <<<<<<< / ======= / >>>>>>> conflict markers manually, then stage the resolved files and continue the cherry-pick:

git add <resolved-file>
git cherry-pick --continue

If you decide the pick was a bad idea partway through, back out entirely with:

git cherry-pick --abort

This restores your branch to exactly the state it was in before you started the cherry-pick.

Cherry-Picking Without Committing Immediately

Sometimes you want to inspect or combine the changes before creating a commit. The --no-commit flag (short form -n) applies the diff to your working tree and staging area without finalizing a commit:

git cherry-pick -n a3f9c21

This is useful when cherry-picking several commits that you want to squash into one, or when you need to tweak the change slightly before it lands.

A Note on Merge Commits

By default, cherry-pick refuses to operate on a merge commit because Git cannot tell which parent's line of history to diff against. If you genuinely need to cherry-pick a merge commit, specify which parent to treat as the mainline with -m:

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

-m 1 means "diff against the first parent," which is almost always what you want when picking a merge commit that came from merging a feature branch into another branch.

Warning: Cherry-picking duplicates history. The picked commit and its original both end up in your repository with different hashes but identical content. If the original commit later gets merged normally into the same branch, Git usually handles the duplicate diff gracefully during a merge, but it can still cause confusing log output. Use cherry-pick deliberately for hotfixes and backports, not as a routine substitute for merging or rebasing.

Practical Use Cases

  • Hotfixes: pull a critical fix from develop straight into production or a release branch without shipping unfinished work.
  • Backports: apply a fix made on the latest release to an older, still-supported release branch.
  • Recovering lost work: if a commit exists on a branch you accidentally deleted but still shows up in git reflog, cherry-pick it onto a live branch to save it.

Once you are comfortable identifying commit hashes with git log, cherry-picking becomes a precise, low-risk way to move exactly the change you need without touching anything else.

Featured Infrastructure Partner

Deploy on High-Performance Hostinger Cloud

Get up to 75% OFF + free domain & SSL. Powering xube.me's sub-second response times.

Claim Discount ↗

Discussion & Insights

Related Technical Essays