I've worked with this approach for the past year: we have a "release" named branch, we deploy that, run all automated tests in production, wait a couple of hour

I've worked with this approach for the past year: we have a "release" named branch, we deploy that, run all automated tests in production, wait a couple of hours for feedback including customer support, then merge it to master. This means master is a history of proven stable builds. And in an emergency you don't have to think about what to roll back to, it's by default master. It's just a convention, it does not have any real benefits or downsides. You could do the same with another branch named stable, or with tags. > a record of every version that was seen by actual users This is covered by the release branches and also by the CD pipeline.