GitHub Cherry Picking: Move Specific Commits Without the Mess

You’re mid-sprint, a bug fix lands in the wrong branch, and now you need that exact change somewhere else—without dragging along everything else. This is where git cherry-pick quietly becomes one of the most useful tools in your GitHub workflow.

Instead of merging entire branches, cherry-picking lets you grab a single commit (or a few) and apply it somewhere else. Clean, precise, and sometimes a little dangerous if you don’t understand what’s happening underneath.

What Git Cherry Picking Actually Does

At its core, git cherry-pick takes the changes introduced by an existing commit and reapplies them as a new commit on your current branch.

Important detail: it doesn’t “move” the commit—it duplicates the changes. That means history is rewritten in a subtle way.

Quick Example

Let’s say your repository looks like this:

• main → stable production code
• feature/login → new login feature

You accidentally fix a production bug inside feature/login instead of main.

Rather than merging the entire feature branch, you cherry-pick just the fix:

1git checkout main
2git cherry-pick <commit-hash>

Now main has the fix—without the unfinished login feature.

Finding the Right Commit

Before cherry-picking, you need the commit hash. The easiest way:

1git log --oneline

Or via GitHub UI:

• Open the repository
• Go to “Commits”
• Copy the commit SHA

Short hashes (like a1b2c3d) usually work fine.

Applying Multiple Commits

Cherry-picking isn’t limited to one commit. You can apply several:

1git cherry-pick commit1 commit2 commit3

Or even a range:

1git cherry-pick commitA^..commitB

This applies everything from commitA through commitB, in order.

Where Things Get Interesting: Conflicts

Cherry-picking can trigger conflicts, especially if the target branch has diverged.

Typical scenario:

• The same file was modified differently in both branches
• Git can’t automatically reconcile changes

When that happens:

1git cherry-pick <commit>

Git pauses and tells you there’s a conflict.

You’ll need to:

1. Open the conflicted files
2. Resolve the differences manually
3. Stage the changes
4. Continue the process

1git add .
2git cherry-pick --continue

If things go sideways:

1git cherry-pick --abort

This restores your branch to its previous state.

A Common Mistake Developers Make

Cherry-picking the same commit multiple times across branches can create duplicate history. This becomes confusing later when:

• Comparing branches
• Running blame or log analysis
• Merging branches again

Because Git sees them as separate commits—even if the changes are identical.

If you expect branches to merge later, excessive cherry-picking can make history harder to reason about.

Cherry Pick vs Merge vs Rebase

It helps to know when cherry-pick is the right tool.

Use cherry-pick when you want precision, not completeness.

Using Cherry Pick in a GitHub Workflow

In team environments, cherry-picking often shows up in these situations:

1. Hotfixes

Fix goes into main, then gets cherry-picked into:

• develop
• release branches

2. Backporting

You apply a fix from a newer version into an older supported branch.

3. Selective Feature Adoption

You only want part of a feature—not the entire branch.

Cherry Picking a Merge Commit (Advanced)

This is where things can get tricky.

If you try to cherry-pick a merge commit:

1git cherry-pick <merge-commit>

Git will complain unless you specify a parent:

1git cherry-pick -m 1 <merge-commit>

The -m flag tells Git which parent to treat as the mainline.

Unless you fully understand your commit graph, this can lead to unexpected results—so use it carefully.

Best Practices That Actually Help

• Keep commits small and focused — easier to cherry-pick cleanly
• Use clear commit messages — helps identify what to pick
• Avoid long-lived divergence — reduces conflicts
• Document cherry-picked changes — especially in teams

One subtle but useful habit: include a reference to the original commit in your message.

1Fix login validation issue
2(cherry picked from commit a1b2c3d)

This makes history traceable later.

When Not to Use Cherry Pick

Cherry-picking is powerful, but it’s not always the right move.

Avoid it when:

• You need the full context of a feature branch
• Commits are tightly coupled
• The branches will be merged soon anyway

In those cases, a merge or rebase will save you from subtle bugs and messy history.

Final Thought

GitHub cherry picking is one of those tools that feels almost too convenient—until you misuse it. Used well, it keeps your branches clean and your fixes targeted. Used carelessly, it creates duplicate history and confusion.

The key is simple: use it for precision, not convenience.