What is git cherry-pick and when is it useful?

Question

IT Interview Practice · Accepted Answer

**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. ## How cherry-pick works ```bash # apply a specific commit from another branch onto the current branch git cherry-pick # → creates a NEW commit on the current branch with that commit's changes # (a copy — new hash, same changes) git cherry-pick # multiple commits git cherry-pick A..B # a range of commits ``` 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. ## Common use cases ```text ✓ 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 ``` ## Cautions ```text ⚠️ 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. ``` ## Why it matters 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.

How cherry-pick works

Common use cases

Cautions

Why it matters

Related questions