Cherry-Picking Commits

Reviewed & published by Brayan K

Sometimes you need just one commit from another branch — an urgent fix, not the whole feature. git cherry-pick is the surgical tool for exactly that. By the end of this lesson you'll copy single commits, ranges of commits, and handle the conflicts that can arise.

Part of the free Git course at LearnCodingFast — hands-on lessons with worked examples and the output they print, plus practice exercises and a quick quiz.

What You'll Learn

• Apply one specific commit with git cherry-pick
• Why you switch to the destination branch first
• That cherry-pick copies (new hash), never moves
• Cherry-pick several commits or a range
• Record the origin with the -x flag
• Resolve conflicts with --continue and bail with --abort

1️⃣ Cherry-Picking a Single Commit

The core workflow: find the commit's hash on its source branch, switch to the branch that should receive it, then run git cherry-pick <hash>. Git applies that commit's changes as a new commit on your current branch — the original stays put on its own branch.

# Scenario: a bug fix landed on "feature", but you need JUST that one
# commit on main right now — without merging the whole unfinished feature.

# 1) Find the commit's hash on the source branch
git log --oneline feature
#   c3d4e5f Fix null-pointer crash   <- we want only this one
#   b2c3d4e Add half-finished form

# 2) Switch to the branch that should RECEIVE the fix
git switch main

# 3) Cherry-pick it — its changes are applied as a NEW commit on main
git cherry-pick c3d4e5f

2️⃣ Multiple Commits & the -x Flag

You're not limited to one. List several hashes to pick them in order, or use a range A..B (which excludes A and includes everything after it up to B). Add -x to stamp each new commit with a "cherry picked from commit ..." line, so you can always trace a fix back to its source.

# Cherry-pick can take more than one commit.

# Several specific commits (applied in the order listed)
git cherry-pick a1b2c3d e5f6g7h

# A RANGE of commits — note A..B EXCLUDES A, includes everything after it
git cherry-pick c3d4e5f..f6g7h8i

# Record where each came from with -x (adds a "cherry picked from" line),
# handy for tracing the fix back to its origin later.
git cherry-pick -x c3d4e5f

3️⃣ Handling Conflicts

Since cherry-pick replays a commit on a different base, its changes can clash with what's already there — a normal merge conflict. Resolve the markers, stage the file with git add, then run git cherry-pick --continue (not git commit). To abandon the whole operation, use git cherry-pick --abort.

# Because cherry-pick re-applies a commit on a different base, it can
# conflict — just like a merge or rebase.

git cherry-pick c3d4e5f
#   CONFLICT (content): Merge conflict in app.js

# 1) Open the file, resolve the <<<<<<< / ======= / >>>>>>> markers
# 2) Stage the resolved file
git add app.js

# 3) Finish the cherry-pick (do NOT run git commit)
git cherry-pick --continue

# Changed your mind? Undo the whole thing:
git cherry-pick --abort

4️⃣ Cherry-Picking a Merge Commit

This is the one that stops people. A merge commit has two parents, so "the changes it introduced" is ambiguous — Git refuses to guess:

Tell it which parent to treat as the mainline — the branch you were on when you merged — and the diff is taken against that side. Almost always -m 1:

-m 1 means "first parent" — the branch that received the merge — so you get everything the merged branch brought in. -m 2 takes the other side and is rarely what you want. Check with git log --oneline <hash>^1 and ^2 if you're unsure which is which.

5️⃣ Staging Without Committing (-n)

Sometimes you want a commit's changes but not its commit — to edit them first, or to squash several picks into one. -n (or --no-commit) applies the change and leaves it staged:

Pick several with -n in a row and they all pile up in the index, so one git commit squashes them together. Note that a -n pick leaves the operation open — git cherry-pick --quit clears that state without undoing your staged work.

6️⃣ --skip: The Third Option During a Conflict

When you pick a range and one commit turns out to be already applied — or its change is no longer wanted — you don't have to abort the whole run. git cherry-pick --skip drops just that commit and carries on with the rest of the range. So mid-conflict you have three exits, not two: --continue to keep it, --skip to drop it, --abort to undo everything.

Your turn. Copy one bug-fix commit from feature onto main. Fill in the two blanks.

# 🎯 YOUR TURN — replace each ___ then run it in your terminal.
# Goal: copy one bug-fix commit from feature onto main.

# 1) Find the fix commit's hash on the feature branch
git log --oneline feature

# 2) Switch to the branch that should RECEIVE it
git ___ main                   # 👉 the command that changes branch

# 3) Apply just that one commit onto main
git ___ <hash>                 # 👉 the command that copies a single commit

# ✅ Expected: "git log --oneline" on main now shows the fix as a NEW
#    commit (different hash), and the file change is present on main.

Common Errors (and the fix)

• Cherry-picked onto the wrong branch: cherry-pick applies to your current branch. Switch to the destination first, then pick.
• Ran git commit during a conflict: use git add then git cherry-pick --continue instead.
• Expected commit A but it was skipped in a range: A..B excludes A. Use A^..B or list A explicitly to include it.
• Duplicate-looking commits after a later merge: the cherry-picked copy and the original both exist; Git usually reconciles them, and -x helps you trace which is which.
• "bad revision" error: the hash is wrong or not visible. Confirm it with git log --oneline <branch>.
• "is a merge but no -m option was given": you picked a merge commit. Add -m 1 to take the changes relative to the branch that received the merge.
• "The previous cherry-pick is now empty, possibly due to conflict resolution": the change is already on this branch, so nothing is left to apply. Run git cherry-pick --skip to move on — or, if you really want the empty commit on the record, git commit --allow-empty, which is what Git itself suggests here.
• Nothing committed after a pick: you used -n, which stages but does not commit. Finish with git commit.

Pro Tips

• 💡 Perfect for hotfixes: pull a single critical fix into a release branch without the unfinished work around it.
• 💡 Use -x for traceability: the "cherry picked from" note makes backports easy to audit.
• 💡 Pick small commits: focused commits cherry-pick cleanly; sprawling ones conflict.
• 💡 Prefer merge for whole branches: cherry-pick is for individual commits, not bulk integration.

📋 Quick Reference

Mini-Challenge: Hotfix Across Branches

No commands given this time — just the plan. Move a single fix from a dev branch to main without the surrounding work.

# 🎯 MINI-CHALLENGE: hotfix one commit across branches.
# No commands given — just the plan. Run each step in your terminal.
#
# 1. On a "dev" branch, make 3 commits; ONE of them is an urgent bug fix
# 2. Note the bug-fix commit's hash with "git log --oneline"
# 3. Switch to main (which should NOT get the other two commits)
# 4. Cherry-pick ONLY the bug-fix commit onto main
# 5. Verify with "git log --oneline" that main got just that one change
#
# ✅ Expected: main contains the bug fix as a new commit, but none of the
#    other two dev commits.

# your commands here

🎉 Lesson Complete!

• ✅ git cherry-pick <hash> applies one commit to the current branch
• ✅ Switch to the destination branch first — it receives the change
• ✅ Cherry-pick copies (new hash); the original commit stays put
• ✅ Pick multiple commits or a range; -x records the origin
• ✅ On conflict: resolve, git add, then --continue (or --abort)

Practice quiz

Continue this course

• Previous: Interactive Rebase: squash, edit, reorder
• Next: Recovering Lost Work with reflog — Rescue lost commits and branches after a bad reset using git reflog
• Quick reference: Git cheat sheet › Rebase & Cherry-pick

Frequently asked questions

What is git cherry-pick?

git cherry-pick applies the changes introduced by one specific commit onto your current branch, creating a new commit there. It's like saying 'I want exactly this change here, but not the rest of the branch it came from.' You switch to the branch that should receive the change, then cherry-pick the commit by its hash.

When should I use cherry-pick instead of merge?

Use merge when you want a whole branch's history integrated. Use cherry-pick when you only need one or a few specific commits — for example, pulling a single urgent bug fix from a development branch into a release branch without dragging along unfinished features. It's surgical: you pick exactly the commits you want.

Does cherry-pick move or copy the commit?

It copies. The original commit stays exactly where it was on its source branch, and a new commit with the same changes (but a new hash, because its parent is different) is added to your current branch. So after cherry-picking, the change exists in two places. If you later merge the branches, Git is usually smart enough to recognise the duplicate.

What happens if a cherry-pick conflicts?

Because the commit is being applied on top of a different base, its changes can clash with what's already there, producing a normal merge conflict. Resolve the conflict markers in the affected files, stage them with git add, then run git cherry-pick --continue. If you'd rather not proceed, git cherry-pick --abort returns your branch to its state before the cherry-pick.

Can I cherry-pick several commits at once?

Yes. You can list multiple hashes (git cherry-pick A B C), and they're applied in the order given. You can also use a range with A..B, which applies every commit after A up to and including B (note that A itself is excluded). The -x flag adds a 'cherry picked from commit ...' note to each new commit so you can trace it back to the original.

Related lessons

• git log
• Resolving Conflicts