There are (at least) two ways to do this.
The way I think most people will recommend is git cherry-pick; you can list the specific commits whose changes you want to apply to the release branch[1]. You can find documentation here: https://git-scm.com/docs/git-cherry-pick
The way I recommend is to use rebase. You can do an interactive rebase, perhaps as simple as
git checkout --detach master
git rebase -i <release_branch>
git branch -f <release_branch>
This will pull up a "to-do list', which you can edit to suit your needs. In this case, you can locate the lines representing the commits whose changes you want, and then delete everything else from the todo list.
Docs: https://git-scm.com/docs/git-rebase
IMPORTANT - note that the rebase is done in detached head state, to avoid moving any refs as part of the rebase; and when it's done you have to update the release branch so it includes the newly copied commits. These are the 'cost' of using rebase for this operation - though depending on preferences there are various ways to address it. But I still personally find it more user-friendly to do this (so git gives the TODO list I can search through and edit) vs. cherry-pick (which requires me to figure out expressions to identify the commits up front).
These methods are in most ways equivalent. A couple things to note:
These commands "copy" the original commit to the new location. The word "copy' is a little misleading here - a patch is calculated for each commit, representing the changes introduced by that commit; and those patches are applied to the new base to create new commits.
In some ways this is like manually applying the changes. In particular, git won't "remember" that the new commits are related to the original commits, so if for some reason you later wanted to merge between master and the release branch there would be potential conflicts - just as your previous manually-applied changes would likely result in conflicts.
But in other ways, this is like doing a weird sort of merge, and that means the cherry-pick or rebase operation itself could generate conflicts (and these aren't always the most intuitive, though most often they're not too bad as long as you think about what the command is trying to accomplish).
[1] - You can identify individual commits by their SHA ID, or by expressions relative to some ref (such as master~2 to mean "the 1st parent of masters 1st parent"). You can specify ranges of commits, like master~6..~master~2, though cherry-pick is a little funny about ranges. IF you follow the docs, they'll take you through many different variations
