No, that's not what I meant and I apologize if it came across that way. What I meant was, it's easy to think of an idealized world where a everything has test s

No, that's not what I meant and I apologize if it came across that way. What I meant was, it's easy to think of an idealized world where a everything has test suites with 100% branch coverage, complete e2e tests, automated screenshot tests of the UI, etc. But, in the real world, that most often isn't true. I've been on a lot of teams. Lots of legacy code has no automated tests at all. Lots of modern code has decent unit test coverage, but nothing for the UI. These are cases necessitating a manual testing step before releasing to prod, and manual testing will often uncover bugs that need fixed. Thus, you need to be able to fix these and continue testing, all the while having as little impact as possible on other Devs working on things unrelated to this release. Having either a single long-lived release/QA branch or shorter-lived release-specific branches accomplishes this in a reasonably simple way. That's what I meant by real-world software development. If you work at a shop with an amazing test suite and don't need these steps, good for you. But, in my 15 years of development, I've never seen a shop like that.