Overview
Cherry-picking allows you to copy specific commits from one branch to another without merging entire branches. It’s useful for applying bug fixes, backporting features, or selectively including changes.Selective Changes
Apply specific commits without merging entire branches
Multiple Commits
Cherry-pick a range or sequence of commits at once
Conflict Resolution
Resolve conflicts just like merging or rebasing
Progress Tracking
Monitor progress when cherry-picking multiple commits
Understanding Cherry-Pick
What is Cherry-Picking?
Cherry-picking creates a new commit that applies the changes from an existing commit:When to Cherry-Pick
Good Use Cases:Bug Fixes
Apply a critical fix from main to a release branch
Backporting
Bring specific features to older versions
Selective Merging
Include specific commits without merging everything
Hotfixes
Apply emergency fixes across multiple branches
- You can merge the entire branch instead
- The commit depends on other commits not being cherry-picked
- You’re duplicating commits unnecessarily
- A proper merge would be cleaner
Cherry-Picking in GitHub Desktop
Cherry-Pick a Single Commit
Find Source Commit
- Switch to History tab
- Browse to the branch with the commit you want
- Locate the specific commit
Cherry-Pick Multiple Commits
Select Commits
In the History tab:
- Click first commit
- Hold
Shiftand click last commit to select a range - Or hold
Ctrl/Cmdto select individual commits
Cherry-Pick Implementation
From the source code:Basic Cherry-Pick Operation
Progress Tracking
Result Handling
Handling Conflicts
When Conflicts Occur
Cherry-picking can cause conflicts when:- The commit modifies lines that differ in the target branch
- Files have been renamed or moved
- Dependencies aren’t present in target branch
Continue After Conflicts
GitHub Desktop preserves empty commits with
--empty=keep, ensuring cherry-picked commits appear in history even if they have no changes.Abort Cherry-Pick
To cancel the cherry-pick operation:Cherry-Pick State Detection
GitHub Desktop detects ongoing cherry-picks:.git/CHERRY_PICK_HEAD exists:
- Cherry-pick is in progress
- Stopped due to conflicts
- Can continue or abort
Reading Cherry-Pick Progress
Merge Commits
When cherry-picking merge commits:-m 1 flag tells Git to use the first parent:
- Parent 1: The branch you were on when merging
- Parent 2: The branch that was merged in
GitHub Desktop always uses
-m 1 when cherry-picking, which means it preserves the changes from the merge commit’s first parent.Empty Commits
Sometimes a cherry-picked commit becomes empty:- Changes already exist in the target branch
- Conflicts were resolved by removing all changes
--empty=keep:
- Commit appears in history
- Maintains commit sequence
- Preserves intent even without changes
Common Cherry-Pick Scenarios
Backport Bug Fix
Apply Hotfix to Multiple Branches
Selective Feature Migration
Best Practices
-
Understand Dependencies
- Ensure commit doesn’t depend on others
- Check if related commits need to come too
- Test after cherry-picking
-
Keep Commit Order
- Cherry-pick commits in chronological order
- Maintains logical sequence
- Reduces conflicts
-
Document Cherry-Picks
- Note in commit message that it’s a cherry-pick
- Reference original commit SHA
- Explain why it was cherry-picked
-
Test Thoroughly
- Cherry-picked code may behave differently
- Ensure tests pass
- Verify integration works
-
Avoid Cherry-Pick Chains
- Don’t cherry-pick cherry-picked commits
- Creates confusing history
- Better to merge or rebase
-
Communicate with Team
- Let others know you’re cherry-picking
- Avoid duplicate work
- Coordinate on shared branches
Commit Message Reference
When cherry-picking, consider adding context:Troubleshooting
Cherry-Pick Results in Empty Commit
Cherry-Pick Results in Empty Commit
If a cherry-picked commit has no changes:
- Changes already exist in target branch
- Commit was already merged differently
- Conflicts were resolved by keeping all current code
--empty=keep to preserve history.Cannot Cherry-Pick
Cannot Cherry-Pick
Cherry-pick is disabled when:
- Uncommitted changes exist (commit or stash first)
- Another operation is in progress (merge, rebase, etc.)
- Working directory has conflicts
- Repository is in detached HEAD state
Conflicts in Every Commit
Conflicts in Every Commit
If cherry-picking multiple commits with constant conflicts:
- Target branch has diverged significantly
- Consider merging instead of cherry-picking
- Or rebase the source branch first
- Cherry-pick may not be the right approach
Lost Cherry-Pick Progress
Lost Cherry-Pick Progress
If cherry-pick state is lost:
- Check
.git/CHERRY_PICK_HEADexists - Try
git cherry-pick --continuein terminal - Check
git statusfor hints - May need to abort and restart
Merge Commit Won't Cherry-Pick
Merge Commit Won't Cherry-Pick
If cherry-picking a merge commit fails:
- Ensure you’re using
-m 1(GitHub Desktop does automatically) - You may need to cherry-pick both sides separately
- Or use
git cherry-pick -m 2for the other parent - Consider whether cherry-picking a merge makes sense
Alternative Approaches
Before cherry-picking, consider:Merge Instead
- If you need most commits from a branch
- Preserves complete history
- Easier to track relationships
- No duplicate commits
Rebase Instead
- If reorganizing commits on same branch
- Creates linear history
- No duplicate commits
- Better for feature branch workflow
Create Patch
- For sharing changes outside Git
- Cross-repository changes
- Manual application needed