Git Cherry-Pick
debt(d7/e5/b5/t5)
Closest to 'only careful code review or runtime testing' (d7). The detection_hints confirm automated=no and the code_pattern describes problems that are only visible through careful branch inspection or when duplicate conflicts surface during eventual merges. Git itself does not warn when cherry-pick is misused, and there is no linter or SAST tool listed that catches it.
Closest to 'touches multiple files / significant refactor in one component' (e5). The quick_fix notes that cherry-pick creates duplicate commits that diverge histories, and fixing this after the fact means reworking branch history — potentially rebasing or re-merging affected branches, which touches multiple branches/commits and is more than a one-line patch but short of a full architectural rework.
Closest to 'persistent productivity tax' (b5). Overuse of cherry-pick creates divergent branch histories that impose ongoing cost: duplicate conflict resolution when branches eventually merge, loss of traceable commit lineage, and the need to remember the -x flag or -m flag conventions. It slows many future work streams without necessarily reshaping the entire system architecture.
Closest to 'notable trap (a documented gotcha most devs eventually learn)' (t5). The misconception field states developers believe cherry-pick creates a reference to the original commit, when it actually creates an independent new commit with a different SHA. This causes the duplicate-conflict problem during later merges — a well-documented gotcha that most developers learn the hard way but does not completely contradict analogous VCS concepts.
Also Known As
TL;DR
Explanation
Cherry-pick is useful for applying hotfixes to multiple release branches without merging entire feature branches. Unlike merge, it does not bring commit history — just the changes. Cherry-picking large ranges of commits is usually a sign that branch strategy needs improvement; prefer merging whole branches when possible. Note that cherry-picked commits are duplicates — both the original and the copy exist in history, which can cause conflicts when the branches eventually merge.
Diagram
sequenceDiagram
participant MAIN as main branch
participant FEAT as feature branch
participant HOT as hotfix branch
Note over FEAT: abc123 - fix critical bug
Note over FEAT: def456 - WIP feature incomplete
Note over FEAT: ghi789 - another WIP
MAIN->>HOT: branch from main
FEAT-->>HOT: cherry-pick abc123 only
Note over HOT: Gets the bug fix<br/>without WIP feature code
HOT->>MAIN: merge hotfix
Note over MAIN: Bug fixed in production<br/>without half-finished feature
Common Misconception
Why It Matters
Common Mistakes
- Cherry-picking many commits when merging the whole branch is simpler and safer.
- Not using -x flag to record the original commit SHA in the cherry-pick commit message.
- Cherry-picking merge commits without -m to specify which parent to use as the mainline.
- Duplicate conflicts when branches eventually merge because the cherry-picked commit is not recognised as already applied.
Code Examples
# Cherry-picking many commits — signals branch strategy problem:
git cherry-pick abc123 def456 ghi789 jkl012 mno345 # 5 commits
# If you need this many, just merge the branch# Hotfix cherry-pick workflow:
# 1. Fix the bug on main:
git commit -m 'fix: prevent negative balance in transfer'
# 2. Cherry-pick to release branch:
git checkout release/2.1
git cherry-pick -x main~0 # -x records original SHA in message
# 3. Push both branches