What Is Cherry-Pick?
Cherry-pick takes the changes introduced by a specific commit and applies them as a new commit on your current branch. The original commit remains in place — cherry-pick creates a copy with the same diff but a different commit hash.
A critical security bug is fixed on the main branch with commit a1b2c3d. You also need that fix on the release/1.x maintenance branch — but you don't want to merge all of main's other changes. Cherry-pick a1b2c3d onto release/1.x and you're done.
Basic Cherry-Pick Usage
# First, identify the commit hash you want to copy
git log --oneline feature/login-form
# a1b2c3d Fix null check in login validation
# 9f8e7d6 Add loading spinner to login button
# ...
# Switch to the target branch
git switch main
# Cherry-pick that specific commit onto main
git cherry-pick a1b2c3dDate: Mon Jun 8 10:22:00 2026 +0000
1 file changed, 3 insertions(+), 1 deletion(-)
The commit is now on main with a new hash (7c3e2f1), but the same commit message and diff as the original.
Cherry-picking multiple commits
# Cherry-pick multiple specific commits (applied in order)
git cherry-pick a1b2c3d e5f6a7b f8c9d0e
# Apply without committing immediately (--no-commit / -n)
# Useful when you want to inspect or modify before committing
git cherry-pick -n a1b2c3dCherry-Picking a Range of Commits
You can cherry-pick a sequential range of commits. Note the important difference between exclusive and inclusive range syntax:
# Range syntax: a1b2..e5f6
# This picks commits AFTER a1b2 up to AND INCLUDING e5f6
# (a1b2 itself is NOT included — exclusive start)
git cherry-pick a1b2c3d..e5f6a7b
# To INCLUDE the start commit, use the caret (^) notation:
git cherry-pick a1b2c3d^..e5f6a7b
# Example: pick last 3 commits from feature branch
git log --oneline feature/payments
# e5f6a7b Add payment success email ← want
# c3d4e5f Add Stripe webhook handler ← want
# a1b2c3d Add payment model ← want
# 9f8e7d6 Setup feature branch ← don't want
git switch main
git cherry-pick a1b2c3d^..e5f6a7bHandling Cherry-Pick Conflicts
If the cherry-picked commit modifies lines that differ between the source and target branch, Git will pause and ask you to resolve conflicts:
git cherry-pick a1b2c3d
# CONFLICT (content): Merge conflict in src/auth.js
# error: could not apply a1b2c3d... Fix null check in login validation
# hint: After resolving the conflicts, mark them with
# hint: "git add/rm <pathspec>", then run
# hint: "git cherry-pick --continue"
# 1. Open the conflicting file(s) and resolve conflicts manually
# 2. Stage the resolved file(s)
git add src/auth.js
# 3. Continue the cherry-pick
git cherry-pick --continue
# OR: Abort the cherry-pick entirely (go back to before it started)
git cherry-pick --abort
# OR: Skip this commit and continue to the next (in a range)
git cherry-pick --skipWhen to Use Cherry-Pick
- Backporting fixes — apply a bug/security fix from
mainto an older maintenance branch - Rescuing commits from abandoned branches — a branch was abandoned but had one good commit worth keeping
- Hotfixes that need to go to multiple branches —
mainandrelease/2.xandrelease/1.x - Applying isolated, self-contained commits — a commit that doesn't depend on other changes in its branch
When to Avoid Cherry-Pick
- Moving entire features — if you need a whole feature branch, use
mergeorrebaseinstead - Commits that depend on others — cherry-picking commit C when it depends on commit B (which you didn't pick) will likely cause conflicts or broken behavior
- Duplicate commits in history — cherry-pick creates a new commit with the same diff but a different hash. If both branches are later merged, Git may apply the change twice or produce confusing history
After cherry-picking commit X from branch A to branch B, both branches have the same change but with different commit hashes. If branch A is later merged into branch B, Git will usually handle this gracefully (recognizing the changes are already applied), but it can occasionally create confusion. Use cherry-pick purposefully, not as a substitute for proper branching strategy.
📋 Summary
- git cherry-pick <hash> — copies a specific commit's changes onto the current branch as a new commit.
- Multiple commits:
git cherry-pick hash1 hash2 hash3(applied in order). - Range (exclusive start):
git cherry-pick a1b2..e5f6 - Range (inclusive start):
git cherry-pick a1b2^..e5f6 - On conflict: resolve →
git add→git cherry-pick --continue - -n / --no-commit — apply changes but don't commit yet (inspect first).
- Best for: backporting bugfixes to maintenance branches.
- Avoid for: moving whole features, or commits that depend on un-picked commits.
FAQ
No. Cherry-pick leaves the original commit completely untouched. It creates a brand new commit on the target branch with the same changes (diff) but a different commit hash, timestamp, and potentially a different author context. The original commit on the source branch is unaffected.
Use git log --oneline <branch-name> to list commits on a specific branch with their short hashes. You can also use git log --oneline --all --graph to see all branches at once. On GitHub, you can find commit hashes in the commit history view and copy them from the URL (e.g., github.com/user/repo/commit/a1b2c3d...).
Both cherry-pick and rebase apply commits from one place to another by replaying their diffs. The key difference is scope: rebase moves an entire sequence of commits (re-applying a branch on top of a new base), while cherry-pick is for selecting individual specific commits. Internally, a rebase is essentially performing cherry-picks of each commit in sequence.
The -x flag appends a line to the commit message indicating the original commit hash: (cherry picked from commit a1b2c3d...). This is useful in public/shared repositories where traceability matters — it makes it clear that the commit was cherry-picked and allows someone to look up the original. For private repositories this is optional, but it's good practice when backporting fixes to maintenance branches.