Introduction

Sometimes one commit contains two or three unrelated changes, but you only want part of it on another branch. Git does not provide a one-command “partial cherry-pick” that selects individual hunks directly, but you can achieve the same result safely by applying the commit without committing, then staging only the parts you want.

That workflow is practical and common. The important goal is to keep the resulting history traceable and to verify that the selected subset still works on its own.

The Standard Partial Cherry-Pick Workflow

The most reliable pattern is:

1. apply the commit without creating a commit
2. unstage everything
3. stage only the wanted hunks
4. commit the selected subset

Commands:

1# On the target branch
2git cherry-pick --no-commit <commit_sha>
3
4# Unstage all applied changes but keep them in the working tree
5git reset
6
7# Stage only the hunks you want
8git add -p
9
10# Create a new commit from the selected changes
11git commit -m "Pick subset of <commit_sha>"

--no-commit is the crucial flag because it applies the patch to your working tree without finalizing history immediately.

When File-Level Selection Is Enough

If you want whole files from the source commit rather than selected hunks, restoring specific files is simpler.

git restore --source <commit_sha> -- path/to/file1 path/to/file2
git commit -m "Pick selected files from <commit_sha>"

For older Git versions:

git checkout <commit_sha> -- path/to/file1 path/to/file2
git commit -m "Pick selected files from <commit_sha>"

This is cleaner than a hunk-based workflow when the desired split happens at the file boundary.

Conflicts and Traceability

Conflicts can still happen during git cherry-pick --no-commit if the target branch differs significantly from the source context.

If that happens, resolve the files first, then continue with the partial-staging workflow.

1git cherry-pick --no-commit <commit_sha>
2# resolve conflicts in editor
3git add <resolved_files>
4git reset
5git add -p
6git commit -m "Pick subset of <commit_sha>"

If the state becomes too messy, abort and start over.

git cherry-pick --abort

A good commit message should mention the source commit explicitly so reviewers can trace provenance later.

1Pick validation fix from abc1234
2
3Selected only input sanitizer and null-check paths.
4Excluded unrelated logging refactor.

Sometimes the Better Fix Is to Split the Source Commit First

If you control the source branch, a cleaner long-term option is to split the original commit with interactive rebase and then cherry-pick the resulting smaller commit normally.

That looks like this in principle:

git rebase -i <base_before_commit>

Mark the commit for edit, reset it, recommit the logical pieces separately, and then cherry-pick the precise one you need.

This approach rewrites source history, so it is only appropriate when that branch has not been shared in a way that would make rebasing disruptive.

Validate the Result Before Pushing

Partial picks are more fragile than full picks because excluded hunks may have contained hidden dependencies. After the new commit is created, inspect it carefully.

git show --stat
git diff HEAD~1..HEAD

Then run focused tests for the touched code. A partial cherry-pick that compiles but loses setup, migration logic, or a related config change can still fail at runtime.

Common Pitfalls

A common mistake is running plain git cherry-pick <sha> first and only afterward trying to edit the resulting commit. That makes it harder to separate the wanted and unwanted hunks cleanly.

Another issue is forgetting git reset after --no-commit, which leaves everything staged and makes selective staging more awkward.

Developers also sometimes partial-pick commits that were never logically separable in the first place. If the original commit mixed tightly coupled changes, the safest fix may be to split it properly on the source branch.

Finally, do not skip testing. Partial picks create custom history, and custom history deserves extra verification.

Summary

• Git does not have a one-command hunk-level cherry-pick, but git cherry-pick --no-commit plus git add -p achieves the same result.
• Use file restore instead when selection happens at file boundaries.
• Mention the source commit in the new commit message for traceability.
• Consider splitting the original commit first if you control the source branch.
• Always validate partial picks with diffs and targeted tests.