Unmerged feature branches until PO-demo versus merged code without feature-flags?
^(Context, not necessary to read:) ^(I work for a company with lots) ^(of web-apps and multiple teams are, often,) ^(dedicated to multiple applications. One app, primarily targeted to internal users, was my focus, on which I solely developed. As of a few months I've been accompanied by a junior dev and dedicated scrum master and product owner. New requirements were set, including code reviews and demo's before production launches.)
The situation: In our current development team, we agreed upon to only have features deployed as agreed upon (live acceptance demo's) by the product owner, primarily to 'ensure' stability and quality. This has resulted in moving to each feature developed on a separate branch and only merge those features into master (& deploy to prod) after a live demo. I still consider this very cumbersome, because those long lived branches (up to 2 weeks) sometimes cause conflicts and it's a bit more difficult to have a prepared acceptance environment.
Curiosity: I want to transition back to a lifecycle where all code, after code reviews, are merged into master, be deployed and prepared on acceptance and, once agreed by the product owner, will be deployed by production. This reduces chances of code conflicts, speeds up the process, ensures a testable environment and more. Do note, and just accept, that feature-flags in our code base are difficult to implement. Only for large impact-heavy features, I'd prefer not to merge early though. I honestly believe, so long we only merge code that has been reviewed, there are little downsides of merging early. I cannot think of a moment were this might have been a real problem and only see opportunities here.
Goal: With this story in mind, what are your opinions about separate feature branches until the demo versus merging reviews code without feature flags? I've had many brainstorms with AI's to seek other perspectives, but actually curious for the expertise of actual brains :)