If I understand you correctly, your current process means that prior to a release, the Main branch will have check-ins for Feature A, Feature B and Bug Fix C. When planning a release, you will merge the check-in for Feature A and Bug Fix C into the Release branch, leaving the changes for Feature B in the Main branch for a future release. Is that correct?
If so, you're essentially using a modified version of the Feature Branch workflow for git. In your case, because of the way TFS works, your Main branch is acting as a holding area for features until they're ready for a release and then you pick and choose which ones you want in your release. With git and the feature branch flow, you have two common options for handling this:
A) Developers branch from the "master" (essentially your release branch) and develop all features in their own branch on their local machines. These branches stay in their local machines until it's time to do a release and then are merged into master as they are desired for a release.
B) If you're using a "master" git repository, your developers still branch from master but instead of keeping the changes local until release time, your developers could push their branches to that repository on feature completion and then they would be merged in when planning a release. The only downside to this particular approach is that your developers will need to do both local and remote branch management, nothing complicated but since branches in git are pointers, when you're "closing" (deleting) a branch pointer, your devs will need to do it on their local machines and someone will need to do it on the master repository as well.
In either case, no need for cherry picking.
And if you or your developers are new to git I strongly recommend the Git for Ages 4 an Up video on youtube. It's an excellent primer for how git works and how it models branches and change sets.
As a minor aside, you'll see lots of references to the "master" branch in git (and likewise to origin when talking about remote repositories). These are just standard conventions. If you wanted your master branch to instead be named Release, you can do that in git with no problems, you'll just need to do the mental substitutions when reading examples and documentation.