git merges operate on different states of the tracked content, not on individual files. Rephrasing, git does not see any fundamental difference between a commit touching two files or a commit touching one file.
There is therefore an expectation in a clean git workflow that there is a thematic coherence in commits and branching strategies. More specifically, it's more "gitty" to produce a commit that fixes a "subject" than a commit that fixes a specific file. It's more "gitty" to have branches that contain work done towards specific "topics" rather than branches addressing the development of specific files.
Relating this back to your question, without knowing too much about your codebase or git strategy, it's possible that the need to merge a specific branch differently according to the state of individual files indicates that the branching model might need a bit of polishing.
If you want the changes in the release branch but not the changes in the README.md file in the release branch then it's possible that the changes in README.md from release might need to be split out somehow so you can merge the release branch without merging changes to README.md. However given that the branch is called release I imagine you don't want to bang on it very hard at all.
If your need to merge from release but ignore README.md changes is recurrent, you might consider setting up a parallel branch to release like release-noreadme. Then you can bang on release-noreadme all you want, including massaging the README.md file to suit your needs, such that you can then merge from release-noreadme without worrying about tiptoeing around specific changes in specific files.
tl;dr: consider having a branch synced to release where you can iron out unwanted changes, then merge from that branch instead of release.