Git Cherry-Pick Explained: Copying Commits Between Branches

Git cherry-pick takes the changes introduced by a specific commit and applies them as a new commit on your current branch, without bringing over anything else from the commit’s original branch. It’s the tool for the narrow case where you want one change from another branch — not all of it — which makes it a deliberate exception to Git’s normal branch-level way of moving work around.

What cherry-pick actually does

Under the hood, git cherry-pick <commit-hash> computes the diff that commit introduced (the change relative to its own parent) and applies that diff to your current branch’s working tree, then creates a brand-new commit with that change. The new commit gets a new hash and a new parent — it is not the same commit object as the original, even though it carries the same author, message, and content by default. This is a meaningfully different operation from merging or rebasing, both of which bring over an entire sequence of commits and preserve their original identity (merge) or replay them in order (rebase). Cherry-pick operates on a single commit in isolation.

git checkout main
git cherry-pick a1b2c3d

This applies the change from commit a1b2c3d — wherever it lives — onto main, as a new commit on top of main’s current tip.

The classic use case: hotfixes

The most common legitimate use of cherry-pick is backporting a fix. Say a bug is fixed on your main development branch, but a release branch for an already-shipped version also needs that fix without pulling in every other change that’s landed on main since the branches diverged. Cherry-picking the single fix commit onto the release branch gets the fix there cleanly, without merging in unrelated feature work that hasn’t been tested for that release.

This pattern shows up constantly in projects that maintain multiple release branches — a security patch, in particular, often needs to land on several supported versions simultaneously, and cherry-pick is the standard way to do it without restructuring branch history.

Handling conflicts

Cherry-pick can conflict just like a merge or rebase can, if the target branch has diverged enough that the surrounding code no longer matches what the commit expects to modify. Git will pause mid-cherry-pick and mark the conflicting files, the same way it does for a merge conflict. You resolve them by hand, git add the resolved files, and run git cherry-pick --continue. If you decide the cherry-pick isn’t worth resolving, git cherry-pick --abort puts you back to where you started.

Useful flags:

• -n / --no-commit — applies the change to the working tree and staging area but doesn’t create a commit, useful when you want to combine it with other changes first.
• -x — appends a line to the commit message noting the original commit hash it was cherry-picked from, which is good practice for traceability.
• A range like A..B cherry-picks every commit in that range, though picking commits one at a time is usually clearer when the goal is a single targeted change.

Why cherry-pick isn’t a substitute for merging

It’s tempting to use cherry-pick as a lightweight alternative to merging an entire feature branch, picking commits over one at a time. This usually backfires. Because each cherry-picked commit gets a new hash, Git no longer sees it as identical to the original — if you later try to merge the source branch normally, Git may not recognize that the change was already applied, leading to duplicate changes or confusing conflicts. Cherry-pick is best reserved for genuinely standalone, single-purpose commits — one bug fix, one small change — not as a way to selectively assemble a large feature out of another branch’s history.

For workflows that need to keep multiple branches or environments in sync predictably, a documented strategy like trunk-based development or GitFlow is a better foundation than ad hoc cherry-picking; reach for cherry-pick as an occasional, deliberate exception within whichever strategy you use, not as your default way of moving code around.

Cherry-pick vs related git operations

	Cherry-pick	Merge	Rebase
Scope	One commit	An entire branch’s commit history	An entire branch’s commit history
Result	New commit, new hash	Merge commit combining both histories	Replayed commits, new hashes
Typical use	Backporting a specific fix	Integrating a completed feature branch	Cleaning up or replaying a branch before merging
History impact	Minimal, isolated	Preserves full branch history	Rewrites commit history

When you’d reach for it in practice

Beyond hotfix backports, cherry-pick is genuinely useful when recovering a commit that was made on the wrong branch by mistake — pick it onto the correct branch, then remove it (or reset) on the wrong one — or when pulling a single useful commit out of a stale or abandoned branch without reviving the rest of it. Debugging with git bisect will sometimes turn up exactly the commit you need without wanting the whole branch it came from, which is a natural moment to reach for cherry-pick. In a monorepo with many independent release trains, cherry-pick is often part of the standard release process rather than an exception at all.

The takeaway

Cherry-pick is a scalpel where merge and rebase are broader tools: it copies exactly one commit’s changes onto your current branch as a new commit, independent of everything else in that commit’s original branch. It’s the right tool for backporting a fix or rescuing an isolated commit — but because it creates a new commit identity, using it as a substitute for merging a whole branch tends to create duplicate-change headaches down the line. Use it narrowly, and it stays a clean, predictable operation.