We have doing feature-based development and once the PR is approved it merged back to master.
When the master is stable in terms of features to go live we make a release branch of it.
Any release specific change will again merge back to master which now making incremental changes ( new changes).
Since the regular changes are now happening on master, my colleague has asked to pluck ( not individual commit, a bunch of commits, otherwise cherry-pick was the option) one feature from master to be made available as a release branch to push on production.
Well, since the feature is developed against incremental changes, it might take a significant amount of time to re-develop according to the 'release' branch.
Please suggest the right branching strategy to handle this scenario.
It sounds like conceptually you want to do a hotfix. To do this you make a new branch from the commit that is currently in production. (Or, if the release branch still exists and you prefer to use that, you could.) Let's refer to that branch as your hotfix branch.
Now you take the set of newer commits that you need from master, and cherry-pick them, in the same order they were created, into the hotfix branch. If there are many commits in the feature, cherry-picking could be cumbersome, so you could use git rebase --onto with 3 arguments to effectively cherry-pick a range of commits all in a single command.
As you pointed out, whether or not you can successfully cherry-pick commits depends on what the changes are, and what other commits they depend on. Perhaps if the feature is self contained it'll work without any issues. I'd say most of the cherry picks I have done have worked flawlessly. Sometimes I'll end up having to pull in additional commits due to dependencies. One time I tried to pull in a set of commits that was so intertwined that I ended up needing to cherry pick over 100 commits just to bring in a feature that itself had only 5 commits. In that case we threw in the towel and said we'd wait until we could release the whole thing. As a general rule of thumb, anytime you cherry-pick a feature for earlier release, testing is key.