[ctennis1]

Yep, but think of all of the private keys and tokens used in automation servers (think CI) for pulling down source. Those don't have 2FA - because they don't login - but they have full access to most source.

In an organization of about 200 engineers across various products, 1000+ github repos, and 10 or so different CI systems. We enforce 2FA at github. I can still easily see how someone could easily gain access to source code with secrets in it.

[ryandrake]

> In an organization of about 200 engineers across various products, 1000+ github repos

Wait, what? That's 5+ repos per engineer. What on earth would warrant that level of granularity? I've only worked once in my career in a place that used more than 2-3 repositories total, and that was a "MegaTechGiant" with thousands of engineers.

[mfrye0]

Depends on the company you work at, but most tech companies I've been at have gone the "micro" services approach.

Example:

- 1 repo for the frontend - 1 for each api - 1 for the infrastructure terraform scripts

It's good for CI / CD and general code base organization. Also easier to track changes and handle security. You give devs access only to the repos they need to do their job.

Our team has a product with multiple integrations and internal apis, so we easily have 40+ repos.

[user2283]

Plus one repo for every open source dependency you fork

[davb]

I know that mentioning downvotes usually invites more downvotes, but...

I'm surprised you're being so heavily downvoted for your question. Engineering teams (and software companies) come in all shapes and sizes. It is absolutely reasonable for even an experienced engineer to have only worked at companies with a handful of repos.

Rather than downvoting, it would have been helpful to explain why your company has opted for such granularity (perhaps engineers or teams have a high level of autonomy, or your software is highly componentised and built from a great many, separately managed, parts).

[jfindley]

Some CI setups benefit from a one-repo-per-service approach, as it makes it easier to figure out when an individual app has changed. In orgs where everything is in one giant repo, it can be difficult to establish what subset of your applications needs to be rebuilt when a commit is pushed.

I personally don't have a strong opinion about either way - they both have tradeoffs.

[6d6b73]

There are just three of us in my company and after 10 years I worked on close to 80 projects for 30 different clients. Each project has its own repo. So +3 per engineer is really not that much;)

[lscotte]

It's normal and expected. I have a few dozen. git makes it great to create little repos for lots of different things. They don't have to be production apps. They can be libraries, utilities, documentation, scripts, or just random crap I may want to refer to someday.

[gjjrfcbugxbhf]

It depends upon the culture. Some places favour a project repo others a repo per microservice/job.

[gutnor]

Could also be a company using clone - pull request workflow. 10-20 project repo an then each developer has a bunch of projects clones, including a few shared one - like the common infrastructure stuff, ...

I can see that with a company that has grown day 1 around Github, especially during early startup stages with a variety of contributors but no formalised "organization".

[jonatron]

Agencies may create multiple repos per client / project.

[ryandrake]

Good point—I can see the point of having numerous repos if you have multiple unrelated clients’ code bases.

[hasan83bd]

How about, if Uber stores all data across those git repositories (1000+)? Perhaps they use git as a multi-versioned data storage? Perhaps better than Kafka (event sourcing thing?). Just a thought :)

[amazingman]

This is almost certainly what actually happened.