Git cherry-pick explained: when to use it (and when not to)

What Is Git Cherry-Pick?

A critical bug fix just landed on your development branch -- but the same bug is live in production. You cannot merge the whole development branch into the release branch, because it is full of half-finished features. What you actually need is to grab that one commit and apply it somewhere else. That is exactly what git cherry-pick does.

Cherry-picking takes the changes introduced by an existing commit and replays them on your current branch as a brand-new commit. The new commit carries the same diff and, by default, the same message, but it has a different parent and therefore a different SHA. This detail matters more than it seems: Git identifies commits by their SHA, so after a cherry-pick your repository contains two distinct commits that happen to introduce the same change. Keep that in mind -- it explains both why cherry-pick is so useful and why overusing it causes pain later.

When Cherry-Picking Is the Right Tool

Backporting a hotfix to a release branch

This is the classic case. You fixed a bug on main, but version 2.3 is what your users are running, and they need the fix now. Cherry-pick the fix onto the release branch:

git switch release/2.3
git cherry-pick a1b2c3d

The release branch gets exactly that fix, and nothing else from main comes along for the ride.

A commit landed on the wrong branch

You meant to commit on your feature branch, but you were on main. Cherry-pick offers a clean recovery: switch to the branch where the commit belongs, cherry-pick it there, then go back and remove it from the branch where it does not belong. If you are unsure about that removal step, our guide on how to undo a Git commit covers each option in detail.

Rescuing one fix from an abandoned branch

Sometimes an experiment does not pan out, but one commit in the middle of the branch fixed a real bug. Instead of merging a dead-end branch, cherry-pick the one valuable commit onto your active branch and let the rest of the experiment be deleted in peace.

Basic Usage

The simplest form takes a single commit:

git cherry-pick a1b2c3d

Git applies the changes from that commit and immediately creates a new commit on your current branch, reusing the original message. You can also pass several commits at once, and Git applies them one by one, in the order you list them:

git cherry-pick a1b2c3d f4e5d6c

Practical Flags You Should Know

-x: record where the commit came from

When backporting, you will later want to know where a commit originated. The -x flag appends a line like (cherry picked from commit a1b2c3d...) to the new commit message:

git cherry-pick -x a1b2c3d

Make this a habit for any cherry-pick between long-lived public branches. Six months from now, that one line will tell you instantly whether a fix made it into a release and where it came from.

Picking a range of commits

You can cherry-pick a whole range with the two-dot syntax:

git cherry-pick A..B

Careful: this applies the commits after A, up to and including B. A itself is excluded. If you want A included, write:

git cherry-pick A^..B

The ^ means "the parent of A", which puts A back inside the range. Mixing these two up is one of the most common cherry-pick mistakes.

--no-commit: apply without committing

Sometimes you want the changes but not an automatic commit -- for example to combine several picked commits into a single one, or to adjust the result before committing:

git cherry-pick --no-commit a1b2c3d

The changes land in your working directory and staging area, and you create the commit yourself when you are ready.

Handling Conflicts During a Cherry-Pick

A cherry-pick can conflict for the same reason a merge can: the commit you are picking was written against code that looks different from your current branch. When that happens, Git stops mid-operation and marks the conflicting files:

error: could not apply a1b2c3d... fix login timeout
hint: After resolving the conflicts, mark them with
hint: "git add/rm <pathspec>", then run
hint: "git cherry-pick --continue"

You now have three ways out:

• git cherry-pick --continue -- after you have edited the conflicting files and staged them with git add, this finishes the cherry-pick and creates the commit.
• git cherry-pick --abort -- cancels the whole operation and returns your branch to the exact state it was in before you started. Nothing is lost, nothing is applied.
• git cherry-pick --skip -- when picking several commits, skips the current one and moves on to the next. Useful when one commit in a range turns out to be already applied or irrelevant.

Resolving the conflicts themselves works exactly like resolving a merge conflict: open each conflicting file, choose between the competing hunks (or combine them), remove the conflict markers, and stage the file. If conflict markers still feel intimidating, our walkthrough on resolving Git merge conflicts visually applies to cherry-picks too.

What NOT to Do with Cherry-Pick

Do not cherry-pick entire branches

If you find yourself cherry-picking five, ten, twenty commits from one branch to another, stop. That is what merge and rebase are for. Both move work between branches while letting Git understand the relationship between them, which keeps future operations cheap and conflict-free. If you are not sure which of the two fits your workflow, our comparison of rebase vs merge walks through the trade-offs.

Duplicated history bites you later

Remember: a cherry-pick creates a new commit with a new SHA, and Git keeps no first-class record that the two commits represent "the same change". If you cherry-pick commits from a feature branch into main and later merge that feature branch anyway, Git has to reconcile two copies of the same changes. Often it quietly succeeds. But as soon as either copy was modified afterwards, you get confusing conflicts where both sides look almost identical -- and your history shows the same change twice, with two dates and two SHAs, which makes tools like git log and git bisect harder to reason about.

A good rule of thumb: cherry-pick is for moving exceptions -- a hotfix, a misplaced commit, a rescued fix. The moment it becomes your routine way of moving work between branches, your history is telling you that the branching strategy needs a rethink.

Cherry-Picking in GitSquid

In GitSquid, cherry-pick lives where you would expect it: right-click any commit on the commit graph and pick the cherry-pick option from the context menu. No copying SHAs back and forth between a log and a terminal.

The bigger win is knowing what you are walking into. GitSquid's Conflict Predictor -- free for everyone -- shows exactly which files will conflict before you run a merge, rebase or cherry-pick, with hunk previews and syntax highlighting. Instead of discovering conflicts halfway through an operation, you see them up front and can decide whether to proceed, pick a different commit, or prepare the resolution calmly.

And when a pick does conflict, "Resolve in scratch worktree" opens a temporary worktree as a new tab, so you can resolve everything there while your active checkout stays untouched.

Quick Reference

Cherry-pick is a scalpel, not a shovel. Used for the occasional precise extraction -- a hotfix backport, a misplaced commit, a rescued fix -- it is one of the most satisfying commands in Git. Used as a substitute for merging, it quietly fills your history with duplicates that come back to haunt you. Know the difference, add -x when you backport, and keep --abort in mind as your escape hatch.

Want to see which files will conflict before you even start? Download GitSquid Free and let the Conflict Predictor take the guesswork out of your next cherry-pick.