git cherry-pick applies a specific commit from one branch onto another — copying just that commit's changes, without merging the whole branch. It's useful for selectively applying particular changes, like backporting a fix.
# apply a specific commit from another branch onto the current branch
git cherry-pick <commit-hash>
# → creates a NEW commit on the current branch with that commit's changes
git cherry-pick <commit1> <commit2>
git cherry-pick A..B
Cherry-pick takes the changes from a specific commit and applies them as a new commit on your current branch — selectively, without bringing along the rest of the source branch.
✓ BACKPORTING a fix — apply a bug fix from main to a release/maintenance branch
(without merging all of main's other changes into the release branch)
✓ Applying a specific commit that's ready, while the rest of its branch isn't
✓ Moving a commit made on the wrong branch to the correct one
✓ Selectively pulling one change from another branch
⚠️ Creates DUPLICATE commits (same changes, different hashes on each branch):
→ can cause confusion/conflicts if branches are later merged (the change appears twice,
though Git often handles it). Prefer merge/rebase for integrating whole branches.
⚠️ Cherry-picking many commits is a sign you might want a merge/rebase instead
⚠️ Conflicts can occur (resolve like a merge); use it deliberately, not as a default
→ Use cherry-pick for SELECTIVE, specific needs — not routine integration.
Understanding git cherry-pick is valuable for selectively applying specific changes, a useful capability for particular situations, so it's practical Git knowledge worth knowing.
The core ability — applying just a specific commit's changes onto another branch without merging the whole branch — addresses real needs that merging can't cleanly handle.
The most common and important use is backporting: applying a specific bug fix from the main branch to a release or maintenance branch, getting just that fix without merging all of main's other (possibly unstable or unreleased) changes into the release branch — a frequent need in maintaining released software.
Other uses include applying a single ready commit while the rest of its branch isn't ready, moving a commit made on the wrong branch to the right one, and selectively pulling one change.
Understanding the cautions is important for using cherry-pick appropriately: it creates duplicate commits (the same changes with different hashes on each branch), which can cause confusion or conflicts if the branches are later merged, so it should be used deliberately for selective needs rather than as a routine integration method (merge or rebase are better for integrating whole branches), and cherry-picking many commits is a sign you probably want a merge instead.
This judgment — using cherry-pick for specific, selective situations (especially backporting) while preferring merge/rebase for routine integration — reflects sound Git practice.
Since selectively applying specific changes (especially backporting fixes to release branches) is a real, occasionally-important need, and since cherry-pick is the tool for it (with cautions about its appropriate use), understanding git cherry-pick — how it works, its key use cases like backporting, and when to use it versus merge/rebase — is valuable, practically-relevant Git knowledge for handling the selective-change scenarios that arise in maintaining and managing software across branches.