Select changes from another Git branch

Choose the operation by what you want to bring over: use cherry-pick for a commit's change, restore for a file snapshot, and patch mode for selected hunks. Start with saved work and a clean index so the imported changes are easy to review.

Apply selected commits

git cherry-pick a1b2c3d

Replace the hash with the desired commit. For a linear, reviewed range from A through B, git cherry-pick A^..B includes A, but the expression follows graph reachability; in a graph with merges it is not simply a visual contiguous list. Inspect the selected commits first.

Resolve conflicts and use git cherry-pick --continue, or return to the starting state with git cherry-pick --abort. Cherry-picking a merge needs an explicit mainline choice and different reasoning.

Take a file or directory snapshot

git restore --source=feature-x -- src/utils.js
git restore --source=feature-x -- src/config/
git diff
git add -- src/utils.js src/config/

This takes the selected paths from feature-x; it does not merge their edits with your current versions. Restore's default non-overlay behavior also removes tracked paths absent from the source tree within the selected scope.

The older form git checkout feature-x -- path updates the index as well as the working tree, and its default overlay behavior can differ for absent paths. Do not treat every checkout and restore variant as interchangeable.

Select hunks interactively

git restore --patch --source=feature-x -- src/app.js

Review each proposed change, then inspect and stage the result. git checkout -p feature-x -- src/app.js is another patch interface, but with an explicit tree it also affects the index for selected changes. Use the command whose staging behavior you intend.

Pause a complete merge for review

git merge --no-commit --no-ff feature-x

When it succeeds, this leaves a merge ready for inspection instead of committing automatically. If you intentionally want one path to retain the pre-merge branch version:

git restore --source=HEAD --staged --worktree -- src/config/
git diff --cached
git commit -m "Merge feature-x with the existing local configuration"

Crucially, the resulting merge commit records feature-x as merged even though you excluded some content. A future merge will not automatically re-offer those excluded ancestor changes. Use selective commits or snapshots when you do not want that ancestry claim. To abandon an in-progress merge, use git merge --abort.

FAQ

Can later merges conflict?

Yes. Cherry-picks create new commits, and file copies do not record a merge relationship. Later merges use ancestry and three-way content comparisons, not a universal “already copied” flag.

How do I inspect branch-specific changes first?

git diff main...feature-x compares the merge base with feature-x. Compare endpoints instead when that is the actual question.

Which version should I restore to exclude a path from a merge?

Before the merge commit is made, HEAD is the current branch's pre-merge tip. origin/main may be stale or differ from that tip, so do not substitute it without checking.

See git-cherry-pick, git-restore, git-checkout, and git-merge.