That seems to be the idea. Even big companies with a monorepo these numbers are insane.

I don’t get the value in capturing so much intermediate state saves as commits either. I understand the “atomic unit of work” idea, but it’s a bad idea masquerading as a good practice.

I use commits to document complete chunks of work I would realistically revert to — which means basically squashed PRs.

To merge 7000 PRs a second is a disaster that even with 100k employees you shouldn’t be able to hit, and your batched deploy pipeline will probably fall over.

I do get the parallel work streams being annoying, but worktrees are built into git now.

I have a python script and shell command to manage worktrees by branch name (it pulls the branch if changed upstream or new, save to a .worktrees folder, copies .env over and stuff like node deps, then it opens a named tmux session).

I type worktree ~/code/repo branch and it sets up a whole environment unambiguously for that work, it’s ready to go in a couple seconds.