We have a ratio of roughly 7:1 (repos to engineers). It was probably closer to 12:1 at some point.

* Spikes/Demo project

* Smaller projects that might have gone live, but have since been migrated elsewhere

* Core services

* Forks of certain supply chain dependencies that we've made improvements to.

My org is currently at 7 people and we have 365 repositories associated with our github org. We've been around for a number of years and I'd guess that impacts the number of repos more than the number of team members.

If they have an architect that loves microservices and thinks every microservice needs its own repo that's what happens (insanity).

Completely normal yes. Repos are cattle not pets.

> Repos are cattle not pets.

What do you mean by this?

A core SRE principle is that "machines/servers are cattle, not pets". They shouldn't be special or bespoke in a way that makes replacement painful or difficult.

I've heard the term used for servers before but not version control repositories. I just don't understand what it would mean for a git repo to be a cattle vs a pet. Like what is an example of a cattle repo vs a pet repo. The metaphore just sounds like gibberish to me idk.

Unless all it means is that that you can have more than a few like the other commenter said but I didn't think that was what the metaphore meant with respect to servers so again I have no idea lol

To me it would mean that a git repo should not have scripts, runners, etc. configured that we don't have the means to easily and readily replace. It should all be documented and understood well enough that we could kill the repo and init another at will.

You can have more than a few