I never found this very compelling. What is main in that world is not the source of truth, and it's rare to have a system atomically in one state or the other - but normally there are progressive rollouts. And if you ever need to rollback in production, I assume no one is changing where main is.

In the scenarios I am thinking of, the only way to rollback production is to update the main branch and redeploy.

But still, it's just the niceness of having the default branch match production or the current release. Even if you're not going through the extra code review or testing, and all you did was automatically point main to the same commit as the latest release tag, it's still nice. Of course, you could have a production branch or whatever, set that as your default, and leave main for development, but the point is the same.

To be explicit for code review, do you mean there is (1) main, (1) development, and then a bunch feature branches - and that there is review when merging into development and main? Having a two-tiered review process seems extremely difficult to do - versus just having more reviewers on the first merge - especially dealing with merge conflicts and needing to merge again into development.

Yes, but merge conflicts are not an issue at all if you don't squash commits on merge, atleast not between development and main. The way we used to do it, was each part of the project had owners with one required to review all changes before merging to development, then any other senior developer could review the merge to main. Though, we would encourage the whole team to review every PR if they had time.

In practice, this was really just a chance to see all the changes going in on this next release.

I think it's worth maintaining the flexibility of how many releases come from a repo. Needing to fork repos just because you want another deployable release in the future seems painful to me.

When the development team is also the operations team it's easier to keep them together and just update the deployment to go to multiple places, which would effectively still be a single deployment.

If they're separate teams, then I would be inclined to give operations it's own repo where they can manage their specific things. With a pipeline that pulls down the artifacts from the development team.

15 years later, Microsoft morged my diagram