I assumed the GP was just concerned about somebody pushing code to a shared trunk branch that happened to break a build. Though as it happens I do know of some shops that literally do have a CI/CD pipeline that's so automated such a push would result in a production update (of course such a set-up wouldn't even allow a push if it did break the build, or cause any of the steps in the pipeline to fail). But yes, I'd normally interpret "pushing code" as pushing to your own feature branch, in which case I'd wonder "is it really so unusual for devs to do this out of hours"? I've certainly done it on weekends before, but with no expectation that anyone would review/merge the changes until normal business hours.
> pushing code to a shared trunk branch that happened to break a build
You revert that commit, then. It's broken. A revert shouldn't be take as some mark of failure or personal offense, it's just that your commit breaks the build, so it's getting removed from `main` until such a time as it doesn't do that. It happens to us all, from time to time. Those reverts almost always carry what at any profession organization should be an implied "feel free to bring this in a PR again, with fixes".
(And ideally, a bit of introspection as to "why didn't CI catch the failure when it was still on a branch?")
Personally I don't see why it's likely to cause major issues to allow people to merge PRs outside of business hours either, but depending on your team workflow and build pipeline (which may not be fully automated for any number of reason) it's not that hard to imagine cases where it's preferable to ensure all pushes to trunk occur during business hours (e.g. for cost saving reasons maybe you don't keep particular services running 24x7 that are needed to allow your integration test suite to run fully).
It’s blatantly obvious that the quote from the article isn’t talking about pushing to #main and potentially breaking production during the weekend. If a team practices true CI/CD, they surely have excellent safeguards and 1-click (if not automated) rollbacks in place.
I imagine the only people who would think otherwise have some pretty dysfunctional repo setups and/or policies.
I sadly suspect the number of development teams with dysfunctional repo setups/policies somewhat outnumbers those with best practice configurations! Actually I can't say I've ever worked anywhere that would truly have qualified for the latter category.
