What is the proper workflow to use git to escalate only certain features to a branch?

Question

I work on a software team working that just switched to git (and GitLab) from TFS.

We have a main branch that should ultimately contain releasable code. The way we get there is that we have a development branch from which all of our developers create "ISSUE" branches. As they finish working on an issue they push their changes to a remote feature branch with the same name. They then create a GitLab "merge" request (which is just the GitLab version of a "pull" request, I think) of the ISSUE branch into development. The team lead reviews and then approves and merges the ISSUE into the development branch.

The development branch is the source for a nightly build that is used by the QA team to test and verify the issue. Now, for the record, all of that is working fine.

But we have ANOTHER team that does UAT testing. For that we have another branch called UAT. The goal, (and the problem I am describing in this question) is that only ISSUES that have passed QA should make it into the UAT branch. The way that we have tried to solve this problem (and which doesn't seem to be working) is that at the time that we merge the dev ISSUE branch into development we use GitLab to cherry pick that completed merge into a merge request into the UAT branch. But, the idea is that we don't approve and merge that ISSUE until it passes QA.

The idea is, by the way, that we would use the same process to get UAT approved ISSUEs into the main branch. (At the time the merge is approved into UAT we create a cherry-picked MERGE into main that we don't approve and merge until the issue passes UAT. ) However, we haven't even gotten that far because we can't get the cherry-pick into UAT to work. The first few work fine but eventually GitLab starts to say...

"Sorry, we cannot cherry-pick this merge request automatically. This merge request may already have been cherry-picked, or a more recent commit may have updated some of its content."

This has got to be a common scenario but, despite a lot of reading, I can't figure it out.

One thing we do, that may be the culprit, is before the dev does the merge request (he has finished work on the issue) he does a git pull origin development so that his issue branch it not behind development. Is that what we are doing wrong?

The bottom line is that we need a worflow that allows us to move an issue from development --> UAT --> main.

I have more info I can post (if needed) as we have CONFLUENCE documents that outlined both the developer workflow and the workflow that moves the issue from the development build to UAT build to main build. But I will see if that is enough information to get some answers for now.

Seth