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.
Practical Use Cases
- Hotfixes: pull a critical fix from
developstraight intoproductionor 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.
Discussion & Insights