This is basically git flow except peer review happens before cutting a release instead of before integrating changes. Even if I worked with a hall of fame team

This is basically git flow except peer review happens before cutting a release instead of before integrating changes. Even if I worked with a hall of fame team of developers, I don't want to integrate your crappy first draft that hasn't been peer reviewed or tested into my work. Generally, if you wouldn't deploy it to Prod as-is, I don't want to build on top of it. When you allow merging of half-done work, it places additional cognitive overhead on each developer they now all have to keep up and be aware of the timeline of each other's changes and are potentially blocked from releasing until all the merged work that isn't yet released is done. There is also the thinking that "developer velocity" = how fast you can merge stuff into a shared integration branch. This is dated, low-ownership thinking that I wouldn't want any team I am on to take part in. The developer is not "done" until it's running in Prod. So you want process that makes that as frictionless as possible, while still having all the peer-review goodness. The best flow I have experienced is dead simple and it's: feature branch -> create PR -> peer-review/manual testing/business sign off -> merge to mainline -> CI/CD runs tests and deploys to Prod (from mainline)