Learn how to use Git cherry-pick for selective commit application between branches. This guide covers conflicts, multiple commits, and advanced cherry-pick scenarios to streamline your workflow.
A bug fix lands on your development branch, but the release branch shipped last week and can’t take the whole branch. You need that one commit, not the twelve around it. That’s the exact moment git cherry-pick earns its keep: it takes the changes from a single commit and replays them wherever you’re standing.
This guide walks through the command from the basic case to the parts that trip people up: conflicts, ranges, cross-repo picks, and the one caveat that decides whether cherry-pick is the right tool or the wrong one. Let’s get into it.
What Is Git Cherry-Pick?
git cherry-pick takes the changes introduced by a specific commit and applies them to your current branch. Merging and rebasing move whole branches around; cherry-pick is surgical. You name the commits you want, and only those changes come across.
Here’s the part most tutorials skip: cherry-pick does not move the original commit. It creates a new commit on your current branch with the same changes and a new hash. The original stays exactly where it was. Keep that in mind, because it’s the root of both the feature’s power and its one real downside, which we’ll get to at the end.
Example: Basic Cherry-Pick Usage
Say you’re on two branches: main and feature-branch. You want one commit from feature-branch applied to main.
# First, switch to the target branch (main)
git checkout main
# Then, cherry-pick the commit from the feature branch
git cherry-pick <commit-hash>
That replays the changes from that commit onto main as a fresh commit. Grab the hash with git log on the source branch.
Why Use Git Cherry-Pick?
A few spots where it’s the right call:
- Backporting fixes: pull a bug fix from a development branch into a release branch without dragging along everything else.
- Syncing features: move one specific change across branches, leaving unrelated work behind.
- Isolating commits: apply a handful of commits without committing to a full merge or rebase.
- Emergency fixes: when production needs one fix now, cherry-pick it in without waiting for the rest of the branch to be ready.
The common thread: you keep branches clean and still get the one change you actually need.
Step-by-Step Cherry-Picking Process
1. Identifying the Commit to Cherry-Pick
First, find the commit. Run git log on the source branch to get the hash.
git log --onelineYou’ll see one line per commit: short hash plus message. Copy the hash of the one you want.
2. Switching to the Target Branch
Cherry-pick applies to wherever you currently are, so check out the target branch first.
git checkout main
Here we’re moving to main, the branch that should receive the commit.
3. Applying the Cherry-Pick
On the target branch, run:
git cherry-pick <commit-hash>
Swap in the real hash and Git replays that commit as a new one on your branch. Two flags worth knowing here. Add -x and Git appends a “(cherry picked from commit …)” line to the new commit message, which is handy for tracing where a backport came from. Add -n (or --no-commit) and Git stages the changes but stops short of committing, so you can tweak them or fold several picks into one commit before you finalize.
Handling Cherry-Pick Conflicts
If the target branch has drifted from the source, the same lines may have changed in both places and Git can’t apply the commit cleanly. It stops and hands the conflict to you.
Example: Resolving Cherry-Pick Conflicts
# After running git cherry-pick, Git might stop and show a conflict message:
CONFLICT (content): Merge conflict in file.txtOpen the file, sort out the conflict markers, then continue the pick.
# Open the conflicting file and resolve the conflict
# Once resolved, add the file to the staging area
git add file.txt
# Complete the cherry-pick
git cherry-pick --continueDecided it isn’t worth it? Back out and leave the branch as it was:
git cherry-pick --abortCherry-Picking Multiple Commits
You can pick a range in one shot, which is useful for a run of related commits.
Example: Cherry-Picking a Range of Commits
# Cherry-pick a range of commits by specifying the start and end commit
git cherry-pick <start-commit-hash>..<end-commit-hash>
One catch that bites people: A..B does not include commit A. The range is everything after the start commit up to and including the end. If you want the start commit in there too, use <start-commit-hash>^..<end-commit-hash> instead. Ranges also assume the commits form a linear sequence, so this is a straight-line-history tool.
Advanced Cherry-Pick Scenarios
Beyond the single-branch case, you can pick across repositories.
Cherry-Picking Across Repositories
Working across two Git repos, add the other one as a remote, fetch it, then pick the commit you need.
# Add the second repository as a remote
git remote add repo2 https://github.com/user/repo2.git
# Fetch the latest commits from the second repository
git fetch repo2
# Cherry-pick a commit from the second repository into your current branch
git cherry-pick repo2/<commit-hash>Same idea as before, just sourced from a different repo instead of a different branch.
Best Practices for Git Cherry-Pick
- Reach for it deliberately. If you’re cherry-picking constantly, that’s a signal a merge or rebase would serve you better.
- Leave a trail. Use
-xor a note in the message so teammates can see where a picked commit originated. - Resolve conflicts carefully. A sloppy conflict resolution is how a “safe” backport ships a bug.
- Don’t pick in bulk out of habit. A wall of cherry-picked commits clutters history and makes changes harder to trace.
The Trade-Off Worth Knowing
Here’s the honest caveat. Because cherry-pick copies a commit rather than moving it, the same change now exists twice with two different hashes: once on the source branch, once on yours. Git treats those as separate commits. Later, when you actually merge the two branches, that duplication can surface as redundant changes or extra conflicts.
So the rule of thumb: cherry-pick when you need one or a few specific commits and nothing else. When you’re moving a whole branch’s worth of work, a merge or rebase is the cleaner path. Use the surgical tool for surgical jobs, and you’ll keep your history readable and your merges boring, which is exactly what you want them to be.