So the management is sold on Git. We currently use Perforce and merge changelists from stage to the release branch when they are ready. The advantage to our currently workflow is we can pick choose which features go to prod and don’t have to worry about a release cycle. Everything goes as soon as it’s tested.
Using Git our workflow will be developers work in a the dev branch or their own. They then merge their changes to the stage ( test) branch for QA to test.
Once QA is done testing the PM will want to merge these changes to the release branch and deploy to Production.
The trick is there are probably 10 things that we are testing in the Stage branch and only one is ready to merge to Release.
I know it’s easy to merge the whole Stage branch to release, but this will never happen. Also using the Git cherry pick is horrible and if we can't merge by branch there isn't much point using Git. In perforce we merged the changlelists from stage to Release.
How do we do this in Git?
Can you give an example?
You could keep the dev branch when doing the merge to the stage branch and merge that dev branch as soon as you want it in production. Keep in mind that this leads to the stage branch being a "dump" branch. Changes done only in that branch will never reach production. Thus fixes need to be done in the regarding dev branch and if integration problems (either merge conflicts or logical conflicts) with two features occur you might need another branch which merges those dev branches. In the latter case those changes can be merged to production only together (using the branch with the conflict solution.)
That said, keep in mind that your stage branch will not contain a very valid state for testing. There might be features which are somehow involved with others, so that merging one of them without the other one won't work. It could happen that you recognize this due to merge errors - but it might also happen that you do not recognize it.
Due to this it might be a better idea to test the features isolated from each other (e.g. each one in its dev branch without the changes from other branches). This might require extra effort to do, as you need complete separate tests incouding environments for that. However it will help you to test the functionality the way it is merged to production. On the other hand this will require to test other features again as soon as you merge anything to production - the test base might have significantly changed.
As long as you are not defining a specified list of features which is merged to production next and can be tested in this combination, there is no perfect technical solution I can imagine. Either you test all future features together - in this case interferences might occur while testing and be missing as soon as the feature is merged. Or you do a test of the separate features and need to retest them after each merge to production to make sure that the two features have no negative conflicts.
Depending on how your teams work it might be a possibility to trust in the ability of the developers to keep possible interferences in mind. However it will happen sooner or later, that this does not work and an error occurs due to the workflow.