Well, it's manual in that when a developer thinks they're done, they open a pull request from feature branch to develop. That's where code review takes place, and as such it's a core part of the workflow. Failing qa might mean additional commits on the feature branch and another pull request to develop. (Develop should really be called testing or qa; historical reasons.)
It sounds to me like the relationship between dev and main is maintained implicitly. At some point dev and main were the same, and from there, any delta that is applied to dev is eventually either applied to main (if it passes QA) or removed from dev (if it fails). If you follow this pattern forever, dev should always be main plus patches currently in QA.
One more question. What if instead of this dev branch people just asked the QA system to run on their feature branches? Would that generate too much work?
I'm imagining that the flow you describe is some kind of convenient or less expensive version of that.
Git having default branch name be "dev" instead of master/main would really clear a lot of misunderstandings and people thinking "main" branch is the stable one.
> The develop branch is main + feature branches currently in qa.
Is any work done to ensure this, or is it just a byproduct of the way of working? I'm struggling to understand how it would just happen automatically.