Git Cherry-Pick — 5 Untraceable Backports
Security found 5 branches with same commit message but no source hash, making fix verification impossible.
-xflag — appends source hash to commit message for traceability--no-commit— stage changes without committing (review before committing)A..Brange syntax — cherry-pick a sequence of commits (exclusive of A)-mflag — required for cherry-picking merge commits (specifies which parent)
Cherry pick applies a specific commit's changes onto your current branch. It solves the problem of needing one fix from another branch without merging everything else on that branch.
The primary use case is backporting: a security fix landed on main, and you need it on release/2.4, release/2.3, and release/2.2 — without pulling in every other change since those releases. Cherry pick with -x gives you the fix with full traceability to the source commit.
Common misconceptions: that cherry pick duplicates the commit (it creates a new commit with the same diff but a different hash), that it's always dangerous (it's the right tool for backporting), and that you can cherry-pick merge commits without special handling (you can't — you need the -m flag to specify which parent to diff against). The real danger is cherry-picking without -x, which destroys traceability across release branches.
Basic Cherry Pick Usage
Find the hash of the commit you want, check out the destination branch, run git cherry-pick <hash>. Git applies the diff from that specific commit onto your current branch as a new commit.
The -x flag appends (cherry picked from commit <hash>) to the commit message. This traceability is not optional for any team maintaining release branches — without it you lose the ability to reason about which fixes have been applied where.
Handling Cherry Pick Conflicts
If the cherry-picked commit touches code that has diverged significantly on the destination branch, you will get a merge conflict. Git stops mid-pick and leaves you in a CHERRY-PICKING state — visible in your shell prompt if you use a Git-aware prompt.
Resolve the conflict files, git add them, then git cherry-pick --continue. If you change your mind, git cherry-pick --abort restores the branch to its pre-pick state.
Cherry Picking Merge Commits: The -m Flag
A merge commit has two (or more) parents. When you cherry-pick a merge commit, Git doesn't know which parent to diff against — it needs the -m flag to specify the parent number.
-m 1 means diff against the first parent (usually the branch that received the merge — typically main). -m 2 means diff against the second parent (usually the branch that was merged in). In most cases, -m 1 is what you want — it applies all the changes that the merge introduced relative to main.
However, cherry-picking merge commits is almost always the wrong approach. The merge commit's diff includes every change from the merged branch, which may be much more than the specific fix you need. Instead, identify the individual commits inside the merge and cherry-pick those.
Backporting Strategy: Multi-Branch Patch Workflow
Backporting is the primary production use case for cherry-pick. A fix lands on main, and you need it on multiple release branches. The workflow must be systematic to avoid missing branches or introducing partial 12 unrelated feature changes, which may introduce new bugs. The discipline: always list the individual commits inside a merge before cherry-picking, and cherry-pick fixes.
The correct order: fix on main first, verify the fix works, then cherry-pick to release branches from oldest to newest. Cherry-picking from oldest to newest reduces conflict probability because each successive branch is closer to main's state.
Always use -x. After cherry-picking to each branch, run the relevant tests on that branch. A fix that works on main may not work on release/2.1 due to API differences.
The Duplicate Commit Problem: When Cherry Pick Meets Merge
Cherry-picked commits have different hashes than the originals. When two branches that both received the same cherry-pick are later merged, Git sees two different commits with the same content and includes both in the merge result. This creates duplicate entries in git log that confuse code review and git blame.
The problem is cosmetic — the code is correct, having the same change applied twice doesn't double the effect. But it clutters history and makes git log harder to read. More importantly, if the cherry-picked commits had different conflict resolutions on different branches, the merge may include both versions, creating a semantic conflict that Git can't detect.
Prevention: cherry-pick to leaf branches only. Don't cherry-pick to both a feature branch and its merge target. If you need a fix on multiple branches, cherry-pick to each leaf branch independently.
| Aspect | git cherry-pick | git merge | git rebase |
|---|---|---|---|
| What it transfers | Specific commits (by hash) | All commits from source branch | All commits replayed on new base |
| Use case | Backporting fixes to release branches | Integrating feature branches into main | Cleaning up local branch before PR |
| History shape | New commit on destination (different hash) | Merge commit with two parents | Linear history (rewritten commits) |
| Traceability | -x flag records source hash | Merge commit references both branches | Commits are rewritten — original hashes lost |
| Safe on shared branches | Yes — creates new commit, no rewrite | Yes — does not rewrite history | No — rewrites history |
| Conflict frequency | Low (single commit's diff) | Medium (all diverged changes) | High (once per commit during replay) |
| Duplicate commit risk | High if cherry-picked to multiple branches | Low — merge commits are unique | N/A — rebase rewrites, doesn't copy |
| Best for | Selective backporting | Team integration | Local branch cleanup |
Key Takeaways
- git cherry-pick -x <hash> applies a specific commit to your current branch and records the source hash in the message — always use -x for traceability.
- Cherry-pick conflicts resolve the same way as merge conflicts: fix the files, git add, then git cherry-pick --continue.
- Never cherry-pick merge commits without understanding -m — cherry-pick the individual commits inside the merge instead.
- Cherry pick is the right tool for backporting fixes to release branches. It's the wrong tool for keeping long-lived branches in sync — use merge or rebase for that.
- Backport from oldest to newest release branch to reduce conflict probability.
- Always test on each destination branch after cherry-picking — the fix may need adaptation for older API versions.
- Cherry-pick to leaf branches only to prevent duplicate commits in merged history.
Interview Questions on This Topic
- QWhen would you use git cherry-pick instead of git merge?
- QYou need to backport a security fix to three release branches. Walk me through the process using cherry-pick.
- QWhat happens if you git cherry-pick a commit that has already been applied to the destination branch?
- QWhat is the -x flag and why is it essential for teams maintaining release branches?
- QHow do you cherry-pick a merge commit? Why is it usually better to cherry-pick the individual commits instead?
- QWhat is the duplicate commit problem and how do you prevent it?
- QHow do you verify that a cherry-picked fix works correctly on the destination branch?
Frequently Asked Questions
What does git cherry-pick do?
git cherry-pick applies the changes introduced by a specific commit onto your current branch as a new commit. It copies the diff from the source commit — not the commit itself — so the new commit has a different hash. It's used to apply specific fixes or features from one branch to another without merging entire branches.
What is the -x flag in git cherry-pick?
The -x flag appends '(cherry picked from commit <hash>)' to the new commit's message. This creates a traceable link back to the source commit, which is essential when maintaining multiple release branches so you can quickly see which fixes have been applied where.
How do I cherry-pick a range of commits?
Use git cherry-pick A..B to apply commits after A up to and including B. Note this is exclusive of A — to include A, use git cherry-pick A^..B. For a list of specific non-consecutive commits, just list the hashes: git cherry-pick hash1 hash2 hash3.
What happens if I cherry-pick a commit that's already been applied to the destination branch?
Git detects that the changes are already present and reports 'The previous cherry-pick is now empty'. If the changes were applied via a different mechanism (manual edit, different cherry-pick with conflict resolution), Git may not detect the duplication and you'll get a no-op commit. Use git cherry-pick --skip to skip empty cherry-picks in a sequence.
How do I cherry-pick a merge commit?
Use the -m flag to specify which parent to diff against: git cherry-pick -x -m 1 <merge-hash>. -m 1 diffs against the first parent (usually main). However, it's almost always better to cherry-pick the individual commits inside the merge instead. Use git log --oneline <merge-hash> ^<merge-hash>^1 to list the individual commits and cherry-pick those.
That's Git. Mark it forged?
3 min read · try the examples if you haven't