- This flow applies more for a service or a website, where there is no problem of distribution: the distribution is done the moment your user reaches your website/service.

- In the case of a website there is one website. In the case of services there may be multiple versions, but they exist together in the same file tree. Fixing an issue on an old version means fixing the issue on specific files; when they're pushed on master the users will get the fix

- An alternative flow of having to manage multiple versions in parallel is to use feature-flags to compartmentalize sections of code that aren't tested yet or not even functional yet. That way you can have everything on a single branch and make all the code aware of each other. Feature flags can be activated gradually in qa environment, then in staging, then in some customers only, etc... to iron out the bugs as deployment goes. Note that this way of doing is also adapted for traditional installable software, see Firefox and Chrome and their myriads of activation flags.

The advantages of feature flags over feature branches are mostly an illusion, though.

Sure, if you're updating your code in co-ordination with updating some external system, such as a database migration, then sometimes deploying in stages with multiple versions of some functionality running concurrently during some of the intermediate stages is more-or-less the only way you can do it without incurring downtime.

But otherwise, even if you have 10 teams and each hides their changes behind a flag and pushes to master instead of a feature branch, you still have an exponentially growing number of combinations and they're still not all being tested in arbitrary combinations. Turning the feature flag on is then little different to merging in a feature branch: it's still a time when things can go wrong. It's just that now they're going wrong on your master branch and screwing things up for everyone else, too.

So you're essentially advocating testing new code, or new combinations of code changes, in production?

For a feature flag to be useful compared to the typical setup where you have a feature branch and then rebase that onto master from time to time until you're ready to do a fast-forward merge, you would need to be testing multiple features concurrently before any of them is merged back to master.

Testing all possible combinations of unmerged features in development is an exponentially difficult problem, so surely no-one is doing that. However, even testing selected combinations still requires someone to be aware of everything that is going on in enough technical detail to highlight potential trouble areas in time to take useful action that would become more difficult once some of those features start to get merged in.

Assuming you have a large enough project that co-ordinating different ongoing development work isn't just handled via informal discussions anyway, that would mean someone has to be identifying risky combinations that could benefit from testing in advance, and someone has to be responsible for doing that testing, and someone has to be responsible for addressing any issues that are discovered as a result. Does anyone here work in a development group that actually does this?

Meanwhile, the cost of using feature flags routinely is clear: every time you do any significant development work, you have to bracket all affected code with a new flag, and someone has to coordinate those flags and make sure they're all tidied up with code left in the "on" mode by release time.

The thing that really helped us was separating the idea of environments and branches.