What are feasible quality criteria for Git repositories?

If you manage a lot of Git repositories (or other, but Git is a specific and common technology), it could happen that depending on users there will be quite different usage profiles. On the worst case end you could face issues with broken repositories (unplanned work, risks) and wasted storage (which is claimed to be cheap but is still accounted for).

Who is responsible for imposing minimum acceptance criteria for "quality of usage" (I cannot find better term for now) and what are realistic quantifiable measures you could install and link to actionables?

Examples of anti-patterns and related risks you might be dealing with:

-
Folks upload files, also binaries, which are neither part of the software nor test documents

-
Binary libraries instead of using dependency management

-
Repos become too big (over 15G as stated here [1])

-
Repos are below 15G but the history is many gigabytes

-
Other?

Or, should anybody care about these things at all? (formal objections, not opinions, why not care)

[1] https://www.quora.com/What-is-the-practical-maximum-size-of-a-Git-repository-full-of-text-based-data

Who is responsible for checking that people don't check in commits that have large files? The same people who are responsible for checking that the commits aren't bad in other ways: everyone.

If git is new in your company, make sure that the git education includes this sort of thing. After that, it's up to code reviewers to notice mistakes and correct them.

If it becomes a repeated problem, then whoever is in charge of developer tooling can write some checks that run every night or whatever and let people know that something slipped through. But that seems like overkill in most situations.

StackExchange DevOps Q#1331, answer score: 5