I mentioned before git cherry-pick(2010), and its issues (commit duplicated, 2010, even though it can be re-applied since Git 2.34, Q4 2021).

But for a file (or files), no need to use the old, obsolete and confusing git checkout command, as in Tyron Wilson's answer

git restore is the right tool (and it is no longer "experimental" since July 2025, Git 2.51).

Suppose the Git commit called stuff has changes to files A, B, C, and D, but I want to merge only stuff's changes to files A and B

Stay on your target branch, and:

git restore --source=stuff --staged --worktree -- A B
git commit -m "Pick files A,B from stuff branch"

By default, git restore affects the working tree; --staged targets the index; using both keeps them in sync.

You can interactively choose hunks within A and B (patch mode) with git restore -p --source=stuff --staged --worktree -- A B.
Note: renames in stuff will not be "followed" by path-limited restore/checkout; you are copying content by current path names.

NeilG asks in the comments:

Could you explain how this works as a checkout?
It feels like you are changing branches, not merging in changes. Or is it like checking-out a particular file from the existing branch - it writes in changes into the working directory from a source?

You are not switching branches or doing a merge. You stay on your current branch: HEAD does not move; no branch switch occurs.
git restore simply copies the content of specific paths (or hunks within them) from a given commit/branch into your index and working tree, after which you make a normal commit.
That is not a merge: there is no merge-base computation, just content transplantation for the listed paths (or hunks).