|$ curl https://forge-ai.dev/api/markdown?path=docs/git/cherry-pick
$cat docs/git-cherry-pick.md
updated Recently·18 min read·published
Git Cherry-pick
Introduction
git cherry-pick applies a specific commit from one branch to another without merging the entire branch. It creates a new commit with the same changes, useful for backporting fixes, recovering lost work, or selectively applying changes.
Basic Cherry-pick
cherry-pick-basic.sh
Bash
| 1 | # Cherry-pick a single commit |
| 2 | git cherry-pick abc1234 |
| 3 | |
| 4 | # Cherry-pick without committing (stage changes only) |
| 5 | git cherry-pick --no-commit abc1234 |
| 6 | # Review changes, then commit manually |
| 7 | git commit -m "Backport: fix login validation" |
| 8 | |
| 9 | # Cherry-pick with a custom commit message |
| 10 | git cherry-pick -m 1 -M "Backport fix to v1.x branch" abc1234 |
| 11 | |
| 12 | # Cherry-pick from a remote branch |
| 13 | git fetch origin |
| 14 | git cherry-pick origin/feature-branch~3 # 3 commits back from tip |
| 15 | |
| 16 | # View the commit before cherry-picking |
| 17 | git show abc1234 |
ℹ
info
Use --no-commit to stage changes without creating a commit. This lets you review the diff, make adjustments, and commit with a custom message.
Cherry-pick Ranges
cherry-pick-ranges.sh
Bash
| 1 | # Cherry-pick a range of commits (exclusive of start) |
| 2 | git cherry-pick abc1234..def5678 |
| 3 | # Applies commits after abc1234 up to and including def5678 |
| 4 | |
| 5 | # Cherry-pick inclusive range (use ^ to include the start) |
| 6 | git cherry-pick abc1234^..def5678 |
| 7 | # Includes abc1234 through def5678 |
| 8 | |
| 9 | # Cherry-pick multiple non-contiguous commits |
| 10 | git cherry-pick abc1234 def5678 ghi9012 |
| 11 | |
| 12 | # Cherry-pick last N commits from a branch |
| 13 | git cherry-pick main~3..main |
| 14 | |
| 15 | # Cherry-pick with merge commit preservation |
| 16 | git cherry-pick -m 1 abc1234 |
| 17 | # -m 1 keeps the parent side of the merge (usually main) |
| 18 | # -m 2 keeps the merged branch side |
Conflict Resolution
Cherry-pick conflicts are similar to merge conflicts. Git pauses and asks you to resolve them before continuing.
cherry-pick-conflicts.sh
Bash
| 1 | # Cherry-pick with conflicts |
| 2 | git cherry-pick abc1234 |
| 3 | # CONFLICT (content): Merge conflict in src/auth.ts |
| 4 | |
| 5 | # Resolve conflicts |
| 6 | # 1. Edit the conflicting files |
| 7 | # 2. Stage the resolved files |
| 8 | git add src/auth.ts |
| 9 | |
| 10 | # Continue cherry-picking |
| 11 | git cherry-pick --continue |
| 12 | |
| 13 | # Or abort and start over |
| 14 | git cherry-pick --abort |
| 15 | |
| 16 | # Skip a problematic commit (in a range) |
| 17 | git cherry-pick --skip |
| 18 | |
| 19 | # Useful during large range cherry-picks |
| 20 | git cherry-pick abc1234..xyz9999 |
| 21 | # If one commit conflicts: |
| 22 | git cherry-pick --skip # Skip the bad one, continue |
| 23 | |
| 24 | # View cherry-pick state |
| 25 | git status |
⚠
warning
Cherry-pick conflicts can be tricky because the commit was originally written against different surrounding code. Take time to understand the original intent, not just the diff.
Common Use Cases
use-cases.sh
Bash
| 1 | # 1. Backport a bugfix to a release branch |
| 2 | git checkout release/1.x |
| 3 | git cherry-pick abc1234 # The fix from main |
| 4 | |
| 5 | # 2. Recover a commit that was accidentally reverted |
| 6 | git cherry-pick abc1234 # The reverted commit |
| 7 | |
| 8 | # 3. Apply a fix from open source to your fork |
| 9 | git remote add upstream https://github.com/original/repo.git |
| 10 | git fetch upstream |
| 11 | git cherry-pick upstream/abc1234 |
| 12 | |
| 13 | # 4. Move a commit between branches (rebase alternative) |
| 14 | git checkout feature-v2 |
| 15 | git cherry-pick main~1 # Grab the latest commit from main |
| 16 | |
| 17 | # 5. Cherry-pick with sign-off (DCO compliance) |
| 18 | git cherry-pick -s abc1234 |
| 19 | # Adds Signed-off-by: Your Name <email> to commit message |
✓
best practice
Use cherry-pick sparingly. Frequent cherry-picking suggests your branching strategy needs adjustment. If you regularly backport to multiple release branches, consider a release-flow workflow or automated backport scripts.
$Blueprint — Engineering Documentation·Section ID: GIT-CP-01·Revision: 1.0