Those counts seem to be wrong. Looking at the code, they seem to count the number of merge commits (commits with >1 parent). However, some nixpkgs committers also use GitHub's rebase merge option. This means the change went through a regular PR + review, but is merged without generating a merge commits. Secondly, some PRs have multiple commits, so even if everything is merged through a merge commit, the number of non-merge and merge commits may not be balanced.

We've grown a lot in last few years and haven't caught up with the policies. See https://github.com/NixOS/nixpkgs/issues/118661 for details.

Note that those statistics are incorrect, but pushes to master still do happen.

It's not fair at all that this is presently the most downvoted comment. Like it or not, this is a real concern, even if the count is illusory. It's not just about humans seeing this, but automated risk assessment tools use this kind of thing as a metric and showing a bunch of commits straight to master can prevent enterprise and government adoption due to policy. Maybe that doesn't matter for you, but innovators ignoring these gigantic market segments is part of why enterprise and government software development remains so far behind the innovation curve because they can't trust the security of the development models and the largest customers are all stuck with effectively no choice but Redhat.