100% Free Forever
AI-Powered Learning
Industry Expert Content
Certificates & Badges
Learn At Your Own Pace
Bash

Cherry-Picking Commits

Cherry-picking applies the changes from a specific commit made on one branch onto another, letting you selectively port individual fixes without merging entire histories.

Rebasing & History RewritingIntermediate8 min readJul 9, 2026
Analogies

Cherry-Picking Commits

git cherry-pick <commit> takes the changes introduced by a single existing commit and reapplies them as a new commit on your current branch. Where a merge or rebase brings across a whole range of history, cherry-pick is surgical: it grabs exactly the diff of one (or a short list of) commits, regardless of where they live in the repository's history graph. This makes it the standard tool for porting an urgent bug fix from a feature branch onto a release branch, backporting a fix to an older maintenance branch, or recovering a single useful commit from a branch you otherwise want to discard.

🏏

Cricket analogy: Like pulling just one standout over from Jasprit Bumrah's spell in a warm-up match and replaying it in the actual final, without bringing the rest of that match along — cherry-pick grabs one commit's exact change, not the whole branch's history.

How Cherry-Pick Works Internally

Cherry-pick computes the diff between the target commit and its parent, then attempts to apply that diff to your current working tree, just like a mini merge. If it applies cleanly, Git creates a brand-new commit with a new hash and (by default) a new author-date/committer combination, but keeps the original author and commit message. The resulting commit is unrelated in the history graph to the original — it is not the same commit reused, but a fresh one carrying identical content. This is why cherry-picking the same logical change onto two branches and later merging those branches can produce a conflict, because Git sees two independent commits rather than one shared ancestor.

🏏

Cricket analogy: Cherry-picking a shot's technique doesn't replay the actual ball bowled — it's a fresh reconstruction of Kohli's cover drive on a new pitch, credited to the same batsman but logged as a separate innings; trying it on two pitches can still clash.

Cherry-Picking Multiple Commits and Ranges

You can cherry-pick several commits at once by listing their hashes, or pick a contiguous range with A..B syntax (exclusive of A, inclusive of B). Passing -n (--no-commit) applies the changes to the index and working tree without creating a commit immediately, useful when you want to combine several cherry-picks into one commit or make small edits first. If a cherry-pick produces a conflict, Git pauses exactly like a merge or rebase: resolve the files, git add them, then run git cherry-pick --continue, or git cherry-pick --abort to back out.

🏏

Cricket analogy: You can replay a whole run of overs from A to B in a practice session, or stage a shot's footwork without officially logging the runs yet (-n); if it doesn't match pitch conditions, you fix your stance, confirm, and continue, or abandon the drill.

bash
# Cherry-pick a single commit onto the current branch
git checkout release-2.4
git cherry-pick 9f8e7d6

# Cherry-pick a range of commits (a1 exclusive, a5 inclusive)
git cherry-pick a1b2c3d..a5b6c7d

# Cherry-pick without immediately committing, to squash into one commit
git cherry-pick -n 9f8e7d6 3c4d5e6
git commit -m "Backport: fix pagination off-by-one (#482, #489)"

# Resolve a conflict mid cherry-pick
git add src/pagination.js
git cherry-pick --continue

# Abort and back out if it's going badly
git cherry-pick --abort

Cherry-picking creates a duplicate commit with a different hash, not a link to the original. If you later merge the two branches that both contain versions of that change, Git may not recognize them as the same edit and can present avoidable conflicts. Prefer merging or rebasing whole branches when you actually want shared history; reserve cherry-pick for targeted, one-off ports.

The name comes from literally picking one cherry (commit) off the tree (history) rather than harvesting the whole branch — you get exactly the fruit you wanted, nothing else, but the branch it grew from is untouched.

  • git cherry-pick <sha> applies one commit's diff onto the current branch as a brand-new commit with a new hash.
  • The original author and commit message are preserved; the committer date and hash are new.
  • Ranges (A..B) and multiple hashes can be cherry-picked in one command.
  • -n/--no-commit stages the changes without committing, useful for combining several picks into one commit.
  • Conflicts pause the operation just like a merge; resolve, git add, then git cherry-pick --continue, or --abort to cancel.
  • Cherry-picking the same change onto multiple branches can cause later merge conflicts since Git treats the picks as unrelated commits.

Practice what you learned

Was this page helpful?

Topics covered

#Bash#GitVersionControlStudyNotes#SoftwareEngineering#CherryPickingCommits#Cherry#Picking#Commits#Pick#Git#StudyNotes#SkillVeris