I seriously doubt there's a single repo on the planet that averages hundreds of commits per minute. That's completely unmanageable for any number of reasons.
[1] https://cacm.acm.org/magazines/2016/7/204032-why-google-stor...
The monorepo case is also a little bit outside what I was originally talking about. I was mostly refering to individual services/libraries/apps
I'd bet there are a more than a few repos that do get (at least) hundreds of commits as a highwater mark. My guess is lots of engineers + mono-repo + looming code-freeze deadline can do that like clockwork.
Edit: Robots too as sibling pointed out. A single human action may result in dozens of bot-generated commits
1) Automated refactoring
2) Automated merges when CI passes
Configs that can be generated should just be generated by the build.
But that's a different topic
- automatic security / vendoring updates (e.g. https://github.com/renovatebot/renovate)
- automated cross-repo syncs, e.g. Google has processes and tools that bidirectionally sync pieces of Google3 with GitHub repos
This depends entirely on the quality of dev tools available.
Also, commit =/= shipped code: you may have a automated commits and keep a human in the loop before shipping, by way of rejectable Pull-Request (or the proprietary equivalent).
A simple library upgrade will result in a wave of commits/bot-authored PRs
1. Human makes a change to a core library, changing it from v1 to v2
2. Bot identifies all call-sites and refactors to v2-equivalent, creating 50 PRs for 50 different teams.
One change, 51 commits.