me either, so now anecdata of 2; but also, sounds insane
of all the things a human should be in the loop for, merging to main seems like one of them
of all the things a human should be in the loop for, merging to main seems like one of them
That's what the review is for. And I'd argue that the review should be decoupled from CI, because you're not reviewing if you think the tests is passing before/after merge, you're reviewing the code and docs themselves.
And once the review is done, it should be fine to merge at any point, today or tomorrow, barring any merge conflicts of course.
Merging to main should be the most mundane task ever, and even a robot should be able to do it with confidence.
Sometimes there are considerations like QA/infrastructure resourcing that dictate when something can go into master. Ideally that's rare but I have worked in a place where it's a consideration for every single merge.
To expand on this a little: we had a simple branching model. To/from master for work, branch from master to cut a release. Being highly regulated, as a matter of (unchangeable) policy, every change needed testing by QA team. QA team == QA guy. Among feature work without hard release dates, there was also bug fixes with some urgency, and regulatory work with hard release dates. Given we traded flexibility in our branching model for simplicity, we instead had to consider if something could be merged to master without impacting QA load of anything already merged but not released. It worked fine for us but were were a team of <5. My remark about trading flexibility is really the crux of it all though. There's compromises that need to made and this one made sense for us at the time.
And if your changes have been QA'd in staging and/or they aren't that hectic (and are backwards compatible) then I think auto merge into prod can be fine too.
I basically do not think "auto merge into prod" is ever OK, but then again, I let GitHub Copilot write 40-60% of my doc comments, so...
Funny how different people can be :) I'll always try to make the main branch so clean that it can be deployed at any moment, and production will always use the latest commit as soon as possible.
Basically, I'm doing CI + CD, but I understand it's not for everyone.