Cherry-Pick Commits

You’re working on a feature branch and spot a security fix you made three weeks ago — but it’s buried in a branch you haven’t merged. You could merge the whole branch, but that would drag in unfinished code and break your release. The solution? Cherry-pick commits to apply specific changes — Git’s surgical tool that copies exactly the commits you want into your current branch, nothing more. This lesson gives you the mental model, the exact commands, and the edge cases to use cherry-picking with confidence.

The problem this lesson solves

Git’s standard workflow is branch → merge or rebase. But merges are all-or-nothing: they pull in every commit from a branch, including work you're not ready to ship. Rebasing is even worse — it rewrites history and can entangle branches you haven't finished.

You need a way to apply a single commit (or a handful) from another branch without touching anything else. That’s exactly what git cherry-pick does. It solves the pain of:

• A hotfix committed on main that you need on an release branch now.
• A bugfix living on an abandoned feature branch that contains 50 other commits.
• Syncing a fix you made on one teammate's branch into your own — without merging their whole world.

Without cherry-pick, you’d be stuck recreating changes by hand (error-prone) or merging and then reverting everything you didn't want (messy).

Core concept / mental model

Think of each commit as a snapshot plus a patch. A commit stores the full state of your files, plus a delta — the exact lines that changed from its parent. git cherry-pick reads that delta and replays it onto your current branch as a brand-new commit.

Here's the key insight: cherry-picking copies, it doesn't move. The original commit stays where it is. Your branch gets a new commit with the same changes but a new hash — because it has a different parent and timestamp.

A useful analogy: you baked a cake (your branch). A friend baked a different cake (another branch). You don't want to combine the two whole cakes — you just want the chocolate icing recipe. Cherry-picking is you asking for the icing recipe, making it in your own kitchen, and adding it to your cake.

Pro tip: Cherry-pick is the opposite of git revert. revert undoes a commit by creating an inverse patch. cherry-pick applies a commit's patch somewhere else. Don't confuse them!

How it works step by step

The core workflow is simple: identify the commit, switch to your target branch, and run git cherry-pick. Here’s the breakdown:

1. Find the commit hash you want to copy from another branch. - Use git log on that branch: git log <branch-name> - Use git log --oneline --all to search across all branches. - Copy the full or abbreviated hash (e.g., a1b2c3d).

2. Ensure your working tree is clean before picking. Stash or commit any local changes — cherry-pick will refuse if it would overwrite uncommitted work.

3. Switch to the branch where you want the changes to land: git checkout <target-branch> (or git switch).

4. Run git cherry-pick <hash> - If the commit applies cleanly, Git creates a new commit automatically and leaves you on your branch. - If there are conflicts, Git pauses and lets you resolve them (more on that below).

5. Verify the result with git log --oneline -1 — you’ll see your shiny new commit.

Cherry-picking multiple commits

You can pick a range or a list. To copy commits from A up to but not including B (where B is newer):

# From hash A (inclusive) to hash B (exclusive)
git cherry-pick A..B

Or explicitly list several hashes:

git cherry-pick 1a2b3c4 5d6e7f8 9a0b1c2

If you want to apply the changes without committing (e.g., to tweak them before committing), use the -n (no-commit) flag:

git cherry-pick -n <hash>

Hands-on walkthrough

Let’s put theory into practice. We’ll create a quick demo repo, make two commits on a feature branch, then cherry-pick just one of them onto main.

Step 1: Set up the scene

mkdir cherry-demo
cd cherry-demo
git init
echo "initial" > app.py
git add . && git commit -m "Base commit"
# Create a feature branch
git checkout -b feature
# Add two commits on feature
echo "bug fix" >> app.py
git add . && git commit -m "Fix login bug"
echo "WIP" >> app.py
git add . && git commit -m "WIP: new feature"
# Back to main
git checkout main

Now main has only the base commit. The feature branch has two extra commits: Fix login bug and WIP: new feature. You want only the bug fix on main.

Step 2: Find the commit

git log --oneline feature

Output (your hashes will differ):

c3d4e5f WIP: new feature
b2c3d4e Fix login bug
a1b2c3d Base commit

Copy the hash b2c3d4e (the “Fix login bug” commit).

Step 3: Cherry-pick it

git cherry-pick b2c3d4e

Expected output:

[main 1f2e3d4] Fix login bug
 Date: Mon ... 1 file changed, 1 insertion(+)

Step 4: Verify

git log --oneline
cat app.py

You’ll see main now has the bug fix commit, but not the WIP commit. feature still has both commits — untouched.

Pro tip: You can cherry-pick from any ref — a branch, a tag, or even straight from the reflog. The source doesn't have to be a branch you've checked out.

Compare options / when to choose what

You've got several ways to move changes between branches. Here's how cherry-pick stacks up:

In practice: Use cherry-pick when you need a specific fix or change on multiple branches (like a hotfix that should have gone to main but went to develop). Use merge when you want to integrate a whole branch. Use rebase when you want to replay your own branch's commits on top of updated main before a pull request.

Variations

• git cherry-pick <hash> -x: Adds a line to the commit message referencing the original cherry-picked commit — great for audit trails.
• git cherry-pick <hash> --edit: Opens your editor so you can change the commit message of the new commit.
• git cherry-pick <hash> -m 1: For merge commits, tells Git which parent to treat as the “main line” (see troubleshooting).

Troubleshooting & edge cases

Cherry-pick behaves well when the patch applies cleanly, but real life gets messy. Here are the common failure modes and how to handle them.

Conflict during cherry-pick

Git stops mid-pick and tells you which files are conflicted. You'll see something like:

CONFLICT (content): Merge conflict in app.py

Resolve it manually (edit the file, remove the <<<<<<< markers), then:

git add app.py
git cherry-pick --continue

If you decide to abort entirely:

git cherry-pick --abort

Pro tip: Before a tricky cherry-pick, create a safety branch: git branch backup — then even if you have to --abort, you haven't lost your footing.

Cherry-pick a merge commit

By default, git cherry-pick <merge-hash> fails because a merge commit has two parents — Git doesn't know which parent to diff against. Use -m to specify the parent number (usually -m 1 for the first parent, i.e., the branch you merged into).

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

The commit disappears afterwards

If you cherry-pick and then someone later merges the original branch, you might get duplicate commits — same changes, different hashes. That’s usually harmless but can confuse git log. To avoid it, note in your commit message that it was cherry-picked (-x helps) and consider whether a merge was actually needed.

“Nothing to commit” error

If you see nothing to commit during a pick, it usually means the changes are already present in your branch (e.g., you cherry-picked the same commit twice). Use git log --oneline to check for duplicates.

What you learned & what's next

You now know how to cherry-pick commits to apply specific changes from one branch to another. You can:

• Identify a target commit with git log.
• Safely apply that commit to your current branch with git cherry-pick.
• Handle conflicts and edge cases like merge commits.
• Choose between cherry-pick, merge, revert, and rebase with a clear rationale.

You’ve built a solid mental model: cherry-pick copies a patch as a new commit, leaving the source untouched. This skill is essential for hotfix workflows, multi-branch maintenance, and keeping your history clean.

Next in the Git Tutorial track, you’ll learn git reflog — how to recover lost commits when things go sideways. That’s the perfect safety net after you’ve started moving commits around with cherry-pick.