Synopsis
git cherry-pick [-n] [-x] [--continue] [--abort] <commit>...Description
The git cherry-pick command applies the changes introduced by one or more existing commits onto the current branch as new commits. It's the right tool when you need a single fix from another branch without merging the entire branch. Cherry-picks create new commits with new SHAs but preserve the original author and message.
Cherry-picking can produce conflicts just like a merge. Use --continue after resolving, or --abort to bail. The -x flag adds a "(cherry picked from commit ...)" line to the message — useful for traceability when porting fixes between maintenance branches.
In day-to-day use, git cherry-pick integrates closely with shell aliases, editor plugins, and continuous integration. Power users often add aliases that combine flags they always pass, or wrap the command in scripts that enforce team conventions. Output formatting can be customized via Git config — pretty formats, color schemes, and pager behavior are all tunable. When something goes wrong, the first diagnostic step is usually to re-run the command with GIT_TRACE=1 in the environment, which reveals the underlying plumbing calls. For unusual situations, the --help output (git cherry-pick --help) opens the full manual page with details on every option, including those rarely used in casual workflows but essential for debugging or scripting at scale.
Understanding how git cherry-pick interacts with the rest of Git's data model — the object database, the index, refs, and the working tree — pays dividends. Each command operates on some subset of these pieces, and knowing which it touches helps predict outcomes and recover from mistakes. Reading the official Git documentation alongside hands-on practice in a throwaway repository is the fastest way to internalize the nuances. Most production issues with Git stem from one of three causes: surprising default behavior, partial network operations, or rewriting history that was already shared. A working mental model of git cherry-pick's side effects helps avoid all three.
Common Options
| Option | Description |
|---|---|
-n, --no-commit | Apply changes but don't commit yet. |
-x | Annotate the commit message with the source SHA. |
-e, --edit | Edit the commit message before committing. |
--continue | Resume after resolving conflicts. |
--abort | Cancel and restore prior state. |
--skip | Skip current commit and continue. |
-m <parent> | Specify mainline when picking a merge commit. |
-S | GPG-sign the resulting commits. |
Examples
git cherry-pick abc123
# Apply a single commit onto current branch
git cherry-pick -x abc123 def456
# Apply two commits with traceability annotations
git cherry-pick A..B
# Pick a range (exclusive of A, inclusive of B)
git cherry-pick --continue
# Continue after fixing conflictsCommon Mistakes
Cherry-picking the same change repeatedly can confuse later merges, since identical-looking commits have different SHAs. Use git rerere to remember resolutions. Picking a merge without -m fails. For long sequences, prefer rebase or merge.
Related Commands
git rebase, git revert, git merge, git rerere