- Readers backporting patches across branches
- Maintainers moving fixes into release lines
Command Reference
git cherry-pick Tutorial
Explains how to apply a selected commit onto the current branch and when cherry-pick is the right tool.
- Awareness that a picked commit may depend on earlier commits
- A judgment about patch transfer versus full branch integration
- Creating duplicated or diverging history across branches
- Ignoring dependency chains and replaying an incomplete patch
The short version
git cherry-pick reapplies the change introduced by a specific commit onto your current branch.
Where it fits best
- backporting a fix into another branch
- selecting only one or two commits instead of merging a whole branch
- moving precise changes into a release branch
Basic usage
git checkout release/1.2
git cherry-pick <commit-hash>
This creates a new commit on the current branch with the same change effect, but not the same commit ID.
Patch on source branch
main
ABC
feature
BDE
Patch replayed on target
release
AR1E'
Typical use cases
Backporting a fix
If a bug is fixed on one branch but you only want that one patch on a release branch, cherry-pick is often the cleanest option.
Selecting one good commit from an experimental branch
When only one or two commits are worth keeping, cherry-pick is usually lighter than merging the entire branch.
Conflict handling
git status
# resolve conflicts
git add <resolved-files>
git cherry-pick --continue
Abort if needed:
git cherry-pick --abort
A practical warning
Cherry-pick is great for precise patch transfer, but heavy use across many branches can make history harder to reason about.
Before you use it
- confirm whether the commit depends on earlier commits
- confirm whether the destination branch already includes a similar change
- confirm whether a full merge would actually be clearer
What problem this command solves in a workflow
git cherry-pick directly affects history shape, ref position, or relationships between commits. The first decision is whether you are organizing private local history or touching history that is already shared with others.
Typical use cases
- Use
git cherry-pickwhen integrating branches, undoing changes, selecting commits, or reshaping a sequence of commits. - Put
git cherry-pickinside a “backup first, mutate second, verify last” flow so higher-risk history operations stay recoverable. - Use
git cherry-pickto understand ancestry, recovery paths, and commit causality during conflict resolution or post-incident analysis.
Diagram view
Commit sequenceCurrent branchAncestry
New commit relationsMoved refsRecovery path
The highest-value preflight question for this category is simple: “Has this history already been shared?”
Special cases and boundaries
- The most expensive failure mode in history commands is rewriting or moving commits that other people already depend on.
- If the operation might affect team flow, run
git status,git log --oneline --graph, andgit reflogfirst so the recovery path is visible. - When in doubt, create a backup branch before continuing so you preserve an obvious way back.
Try it yourself
This drill helps you see that cherry-pick transfers change intent, not the original commit identity or parent chain.
git switch -c release/1.2 # create a separate feature branch with one bug-fix commitTry it
- Copy the hash of the fix commit from the feature branch.
- Switch back to the release branch and run `git cherry-pick <hash>`.
- Inspect the result with `git log --oneline --graph --decorate --all`.
- The target branch gets a new commit with similar content but a different ID.
- The original parent chain is not copied over.
- For patch-level backports, this is often more precise than a full merge.
- If the picked commit depends on earlier commits, cherry-picking it alone may leave the target incomplete.
- If equivalent changes already exist, repeated cherry-picks can make history noisy.
- If the real need is the whole branch history, merge is usually clearer.