Let’s build a precise, plain-English definition before touching any internals.

The Simple Definition

git cherry-pick is a command that takes the changes introduced by one specific commit — anywhere in your project’s history, on any branch — and applies those same changes as a brand-new commit on the branch you’re currently on. The original commit stays exactly where it was; cherry-picking creates a fresh copy of its changes elsewhere, with a new commit identity of its own.

Why This Command Exists

Most of the time, when you want changes from one branch on another, a merge or a rebase is exactly the right tool — they bring over everything a branch has to offer. But sometimes you genuinely want just one specific change, and nothing else that branch contains. Maybe a critical bug fix was made on a long-running experimental branch that isn’t ready to be merged in its entirety. Maybe you need to apply the exact same small fix to three different release versions of your software. git cherry-pick exists precisely for these narrow, surgical situations, where a full merge would be the wrong tool for the job.

Cherry-picking only makes sense once you understand exactly what’s being copied, so let’s ground ourselves here first.

A commit is a saved snapshot of your entire project at one specific point in time, along with a description of what changed and who made the change. But Git doesn’t store a commit as a standalone island — every commit (except the very first one in a project) also remembers which commit came directly before it, called its “parent.” This chain of parent links is what forms the branching, weaving structure of a project’s history that tools like Git log visualize as a graph.

Now let’s open the hood and walk through exactly what Git does, step by step, when you cherry-pick a commit.

graph LR
    subgraph "Source Branch"
    P1[Parent Commit] --> C1[Commit X - the fix]
    end
    subgraph "Your Branch"
    P2[Your Latest Commit] -- cherry-pick Commit X --> C2[New Commit X' - same change, new identity]
    end
        

Zooming out from the internal mechanics, here’s what the whole process looks like from a developer’s point of view, start to finish.

sequenceDiagram
    participant You as Your Branch
    participant Src as Source Commit (elsewhere)
    You->>Src: Identify the exact commit to copy
    You->>You: Switch to the branch that should receive it
    You->>You: Run cherry-pick, pointing at that commit
    You->>You: Git computes and attempts to apply the diff
    alt Applies cleanly
        You->>You: New commit created automatically
    else Conflict detected
        You->>You: Git pauses, marks conflicting lines
        You->>You: You manually resolve, then continue
    end
    You->>You: Cherry-pick complete — new commit now on your branch
        

Notice that this lifecycle mirrors, in miniature, the same automatic-versus-manual logic you’d find in a full merge — Git tries its best to combine things automatically, and only asks for human judgment when it genuinely can’t decide safely on its own. Cherry-picking is, in a sense, a merge scaled down to the size of exactly one commit.

Cherry-picking isn’t limited to exactly one commit at a time — it can also be used to copy over a whole consecutive sequence.

Single-Commit Cherry-Pick

The most common and straightforward case: you identify one specific commit, and Git recreates just that one change on your branch. This is the scenario most people picture when they think of cherry-picking.

Range Cherry-Pick

Git also supports specifying a consecutive range of commits, applying each one, in order, as its own separate new commit on your branch. This is useful when several related commits together form one coherent piece of work you want to copy as a group, rather than cherry-picking each one individually by hand.

This is the part beginners find most intimidating, so let’s demystify it fully, the same way we would for a merge.

A conflict happens when the surrounding code on your current branch has diverged enough from the commit’s original context that Git can’t confidently figure out where the change belongs anymore. Remember, Git is applying a diff — a description of “change line 12 from this to that” — and if line 12 on your branch no longer matches what the diff expects to find there, Git has no safe way to guess what you’d want instead.

Once you understand why a conflict happens, resolving one is a calm, mechanical process, very similar to resolving a merge conflict.

These three commands all combine changes from one place into another, but at very different scopes and with very different intentions.

A few options change the default behavior of cherry-pick in ways you’ll run into regularly. Here they are, described conceptually.

Like every precise tool, cherry-picking brings genuine benefits alongside some sharp edges worth understanding.

Cherry-picking touches a few security-relevant scenarios worth being aware of.

Over years of real-world use, a few clear patterns of good and bad cherry-pick usage have emerged across teams.

A practical checklist for using cherry-pick the way it’s genuinely meant to be used.

Cherry-picking sits quietly behind several important, everyday practices across the software industry.

No. The original commit stays exactly where it was, completely untouched. Cherry-picking only creates a new, separate commit elsewhere with the same changes.

Not automatically in a structural sense, though many teams add a note in the new commit’s message referencing the original commit for future clarity.

Not directly — cherry-pick works within the history of a single repository. To bring in a commit from an entirely separate repository, you’d first need to connect the two histories in some way.

Git will attempt to apply the same change again. If nothing on your branch has changed since the first cherry-pick, this second attempt will usually have nothing meaningful left to apply, or may create an empty commit.

No — unlike a rebase, cherry-picking never alters any existing commit. It only ever adds a new commit, making it just as safe to use on shared branches as a regular merge.

Yes, though it requires telling Git which of the merge commit’s multiple parents should be treated as the baseline for computing the diff, since a merge commit doesn’t have just one.

git cherry-pick is Git’s tool for surgically copying the effect of one specific commit onto your current branch, without bringing along the rest of that commit’s original branch. Under the hood, it computes the commit’s diff and attempts to reapply it on top of your branch’s latest commit, creating a brand-new commit with its own identity while preserving the original author’s credit. It’s an invaluable tool for backporting critical fixes and rescuing isolated good work from otherwise-discarded branches, but its power comes with a responsibility to use it deliberately, rather than as a routine substitute for merging or rebasing.