Chapter 5.4 — Cherry-pick☕ 16 min read

Cherry-pick — Selective Commit Transfer

Cherry-pick = precision tool. Poora branch merge karna hai toh merge use karo.

01What is Cherry-pick

git cherry-pick <hash> copies a specific commit from one branch to another. It does NOT merge the entire branch — only the exact changes from that one commit.

Cherry-pick creates a NEW commit with the SAME changes but a DIFFERENT SHA hash. The original commit remains untouched on its branch.

Common use cases:

Hotfix backport: apply a security fix to multiple release branches
Selective feature: take one commit from a long feature branch without merging everything
Undo by cherry-picking: cherry-pick a revert commit to undo a change on another branch

Cherry-pick respects the commit's author and date metadata by default, preserving the original attribution.

# Main has the hotfix
git log --oneline main
# abc1234 fix: security vulnerability
# def5678 feat: new feature

# Apply ONLY the hotfix to release branch
git checkout release/v1.0
git cherry-pick abc1234
# Creates a new commit on release/v1.0 with same changes
# New hash: xyz9876, but same diff

# Cherry-pick multiple commits
git cherry-pick abc1234 def5678
# Both commits applied in order

# Cherry-pick a range (exclusive start, inclusive end)
git cherry-pick hash1..hash3
# Applies hash2 and hash3 (not hash1)

02Basic Cherry-pick

Cherry-pick computes the DIFF introduced by the source commit, then applies that diff to your current branch.

The resulting commit has: new parent (your current branch tip), new tree (after applying diff), new hash.

Same changes, different context. If the source commit changed lines that have been modified on your branch, you get a CONFLICT.

Cherry-pick does NOT copy the commit — it REAPPLIES the changes in a new context. This is why cherry-picked commits have different hashes — they have different parents and potentially different results.

💡 Pro Tip: Think of cherry-pick like photocopying a page from someone's notebook and pasting it into yours. The content is the same, but the page number (hash) is different because it's in a different book (branch). If your notebook already has something written where you're pasting, you get a conflict.

03Cherry-pick Range

Conflicts happen when the cherry-picked commit changed code that's different in your current branch. Resolution is same as merge: fix markers, git add, then git cherry-pick --continue.

Abort: git cherry-pick --abort — cancels and returns to previous state
Skip: git cherry-pick --skip — skip this commit and continue with next (if cherry-picking multiple)

Cherry-pick conflicts are often harder than merge conflicts because you're applying changes out of their original context.

# Cherry-pick a commit
git cherry-pick abc1234
# CONFLICT (content): Merge conflict in app.js

# Option 1: Resolve and continue
# Edit conflicted files
git add app.js
git cherry-pick --continue

# Option 2: Abort entirely
git cherry-pick --abort
# Back to clean state before cherry-pick

# Option 3: Skip (when cherry-picking multiple)
git cherry-pick --skip
# Skip this commit, continue with next

# Pro tip: cherry-pick with no auto-commit
git cherry-pick -n abc1234
# Changes are staged but not committed
# Review with git diff --staged before committing
git commit -m "cherry-pick: fix security issue"

04Conflict Handling

git cherry-pick -x <hash> adds a line to the commit message: (cherry picked from commit <hash>)

This creates an audit trail: you can trace where the change came from. Without -x, there's no link between the cherry-picked commit and the original.

ESSENTIAL for backporting hotfixes — you need to know which original commit this came from. Some teams require -x for all cherry-picks to production branches.

# Regular cherry-pick: no origin info
git cherry-pick abc1234
# Commit message: "fix: security vulnerability"
# No way to know this came from abc1234

# Cherry-pick with -x: includes origin
git cherry-pick -x abc1234
# Commit message:
# fix: security vulnerability
#
# (cherry picked from commit abc1234)

# Why this matters:
# 6 months later, someone asks "where did this fix come from?"
# git log shows the cherry-pick source
# You can look up the original PR, context, and discussion

# Team policy: always use -x for release branches
git checkout release/v2.0
git cherry-pick -x <hotfix-hash>

05When to Use

Hotfix backport: fix on main → cherry-pick to older release branches. This is the most common and safest cherry-pick use case.

Selective feature: take one commit from a feature branch without merging everything. Useful when a feature branch has many experimental commits but only one is production-ready.

Undo and redo: cherry-pick a revert commit to undo a change on another branch.

Build release: cherry-pick specific commits into a release branch.

DANGER: cherry-picking then merging the original branch causes DUPLICATE commits. Git doesn't track cherry-pick relationships for merge purposes. Avoid cherry-pick if you'll eventually merge the full branch — use merge or rebase instead.

# Scenario 1: Hotfix backport
# Fix applied to main, need it in v1.0 and v2.0
git checkout release/v1.0
git cherry-pick -x <hotfix-hash>

git checkout release/v2.0
git cherry-pick -x <hotfix-hash>

# Scenario 2: Selective feature
# Feature branch has 10 commits, you only want 2
git checkout main
git cherry-pick <commit1-hash> <commit2-hash>

# Scenario 3: Build release branch
git checkout -b release/v3.0
git cherry-pick <feat1-hash> <fix1-hash> <feat2-hash>

# DANGER: Duplicate commits
git checkout main
git cherry-pick <feature-commit>  # commit A'
git merge feature-branch          # includes original commit A
# Now main has BOTH A and A' (duplicate changes!)

Cherry-pick is a precision tool, not a replacement for merge. The #1 mistake: cherry-picking from a branch, then later merging that same branch. This creates duplicate commits because Git doesn't track cherry-pick relationships for merge purposes. Rule: if you'll eventually merge the full branch, DON'T cherry-pick from it. Use cherry-pick only for commits you won't merge any other way (hotfixes, selective backports).

Lo kar liya — Key Points:

✅ git cherry-pick <hash> copies a specific commit from one branch to another
✅ Cherry-pick creates a NEW commit with the same changes but a different SHA hash
✅ Use cherry-pick for hotfix backports, selective feature adoption, and release branch building
✅ git cherry-pick -x adds origin tracking: "(cherry picked from commit <hash>)"
✅ Cherry-pick conflicts occur when the target branch has different code in the same area
✅ Cherry-picking from a branch then merging it later creates duplicate commits
✅ Use cherry-pick for precision — only when you don't plan to merge the full branch

Previous5.3 — Interactive Rebase — squash, reorder, edit 📋 All Chapters Next Chapter5.5 — When NOT to Rebase →