Skip to main content

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
Avoid Cherry-Picking When:
  • 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

1

Checkout Target Branch

Switch to the branch where you want to apply the commit
2

Find Source Commit

  • Switch to History tab
  • Browse to the branch with the commit you want
  • Locate the specific commit
3

Start Cherry-Pick

Right-click the commit and select Cherry-pick commit
4

Resolve Conflicts (if any)

If conflicts occur, resolve them in the Changes tab
5

Complete

The commit is applied to your current branch with a new SHA

Cherry-Pick Multiple Commits

1

Select Commits

In the History tab:
  • Click first commit
  • Hold Shift and click last commit to select a range
  • Or hold Ctrl/Cmd to select individual commits
2

Cherry-Pick Selection

Right-click and select Cherry-pick X commits
3

Monitor Progress

Watch the progress bar as commits are applied
4

Handle Conflicts

Resolve conflicts for each commit as they’re encountered

Cherry-Pick Implementation

From the source code:

Basic Cherry-Pick Operation

Progress Tracking

GitHub Desktop parses Git’s output to show real-time progress:

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
1

Cherry-Pick Pauses

GitHub Desktop stops and shows conflicted files
2

Review Conflicts

Check which files have conflicts in the Changes tab
3

Resolve Each File

  • Open in editor to manually resolve
  • Or use “ours” / “theirs” for simple cases
4

Continue Cherry-Pick

Click Continue cherry-pick after resolving

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:
1

Click Abort

Click Abort cherry-pick in the banner
2

Confirm

Confirm you want to discard the cherry-pick
3

Return to Previous State

Repository returns to state before cherry-pick

Cherry-Pick State Detection

GitHub Desktop detects ongoing cherry-picks:
If .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:
The -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
GitHub Desktop handles this with --empty=keep:
This ensures:
  • 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

Cherry-pick sparingly: Consider whether a merge or rebase would be more appropriate before cherry-picking.
  1. Understand Dependencies
    • Ensure commit doesn’t depend on others
    • Check if related commits need to come too
    • Test after cherry-picking
  2. Keep Commit Order
    • Cherry-pick commits in chronological order
    • Maintains logical sequence
    • Reduces conflicts
  3. Document Cherry-Picks
    • Note in commit message that it’s a cherry-pick
    • Reference original commit SHA
    • Explain why it was cherry-picked
  4. Test Thoroughly
    • Cherry-picked code may behave differently
    • Ensure tests pass
    • Verify integration works
  5. Avoid Cherry-Pick Chains
    • Don’t cherry-pick cherry-picked commits
    • Creates confusing history
    • Better to merge or rebase
  6. 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:
Or let Git add it automatically:

Troubleshooting

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
GitHub Desktop keeps the commit with --empty=keep to preserve history.
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
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
If cherry-pick state is lost:
  • Check .git/CHERRY_PICK_HEAD exists
  • Try git cherry-pick --continue in terminal
  • Check git status for hints
  • May need to abort and restart
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 2 for 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