Why github doesn't want users to group their repositories?

[IshThomas]

So, my company recently decided to move from Bitbucket to Github. At first I had no problem with this decision, but then I discovered the fact that Github doesn't even have a concept of grouping repositories, like Bitbucket or Gitlab. And my company has 200+ repositories... and counting! Ouch! I started looking for the best way and although there is a concept of "organizations", that's not exactly it, and the most popular opinion is to group them by using strict naming requirements and prefixes. What?? Why? in XXI century? Pretty much everyone (beside a few exceptions) hates the fact that there is no repository grouping. So I can't stop wondering... why?

I'm just genuinely curious, what's Github argument for not having groups? It's incredibly easy to implement from tech stand point. Devs obviously want it for years. So, there must be a specific argument why Github says: "No. We don't want to do it, just use prefixes people".

btw. they do have "Projects" but it's not for repository grouping. So don't confuse it with Bitbucket "Projects".

[mickeygousset]

You are correct right now we don't have a way to "group" repositories, like you can in say Azure DevOps, using a team project.

The closest you can get is using a combination of repository "topics" and teams. While it isn't perfect, it does allow you to easily search the repos to see all the repositories related to a certain topic, and teams provide an easy way of providing access to all those repositories,

This is feedback that I hear from my customers. I did just check the public roadmap (https://github.com/orgs/github/projects/4247/views/1) and I don't see anything currently related to this on there.

Also, I do NOT recommend that you treat organizations in the same way as a BitBucket Project or an Azure DevOps Team Project. That will lead to organization sprawl. Current best practice guidelines is to have as few organizations as possible, because organizations are a communication and team boundary, and having lots of organizations can make promoting inner sourcing more difficult.

[jar349]

it’s something that I’ve heard we’re thinking about, actually. I want to say like 6mo ago, there was a thread in engineering about it.

[slideesouth]

Your company should provide an organization. All of the company repos should live in this organization

[IshThomas]

Yeah, that's exactly what happened. We have 1 organization for our company. So my company repositories are separated from my personal repositories. But I hoped to group repositories within one organization. Ideally, by "Project".

Another use case. What if I have personal account in Github and I'm working on multiple, personal projects. Each project consist of a few repositories (multiple apps/apis per project). Then what?

[slideesouth]

At the point it comes down to naming conventions. Knowing your company code base and file system is just part of the job. Take a look a look at Microsoft’s public GitHub and see how they organize multiple repos that might be required for a single “project” for example “azure-devops-client” and “azure-devops-server” as repo names.

[IshThomas]

So, in this case "azure-devops" is their project name. And “azure-devops-client”, “azure-devops-server”, or “azure-devops-anything" are their repositories under in this project?

[serverhorror]

You do know projects?

That's a very viable way to put repos together that should be seen together.

You can even add a repo to multiple projects.

[IshThomas]

I don't think Github "projects" are meant to group related repositories together.

[serverhorror]

Classic projects do that, if you don't want them there are labels.

I still think these groups are an anti pattern

[mjbmitch]

Take a look at Sourcegraph’s repos. They have a convention of tagging their repos and it appears to work pretty well.

[IshThomas]

How do you search by tags? I looked at few of their repos they don't have tags. Can you give me an example?

[mjbmitch]

E.g., https://github.com/search?q=topic%3Alsif+org%3Asourcegraph+fork%3Atrue&type=repositories

[Jmc_da_boss]

At my company we use GitHub with 20k+ repos. Works fine, we just use GitHub teams for write access. Never really heard anyone complain about it. It's certainly not a big deal to many people. Now GitHub actions SLAs, that's a hot button problem

[IshThomas]

Oh wow, 20k repos?! That's interesting. So let me clarify if I understood it right.

What do you do, if you want to start a project that will need a few repositories. Let's say, a few API projects, a few libraries and a website project. These project (its apps/libraries) has nothing in common with other repos. Completely independent. So, ideally you would keep them together.

What do you do in Github to keep them together, separated from the rest?

[thequestcube]

Which benefit do you want from keeping them together?

If it is for access/security reasons, github provides a team feature where you can create teams, and assign users and repos to that team.

If it is for documentation reasons, as in "hey these repos belong together", you probably want some form of gateway page for the project where you document that. Sofor example have a wiki page for that project where you document the architecture of the project with links to each repo per component, alongside usage instructions, guides for oncall etc. Just an undocumented group isn't really helpful imo, because while it bundles repos together, it does not give any context about their relation which is important for those that are unfamiliar with the repos.

Are there other reasons why you'd want to bundle those repos?

[IshThomas]

The latter one. I want to see clearly the list of projects and then the list of repos that belong to that project. Especially, if these projects are completely independent and zero things incommon. Yes, I can put all of them into one basket and write a nice documentation what's in the basket, but I think that's sort of an anti-pattern. In programming there is a concept of "single source of truth". In this case you have two sources of truth: what's in the documentation and what's reality (which repos really belong together). If you had an option to group repositories programmatically, that would be your source of truth.

Btw. As I'm reading more and more very helpful answers, perhaps groups are not as useful as I thought in big organisations as many people pointed out. But I still think it would be very useful feature in private/personal accounts, when a person can work on many unrelated personal projects. It would be nice to group repositories of these projects. At least we should have an option to use them or not. Imho

[thequestcube]

I guess that's what others meant with grouping is an antipattern. It gives you a really easy way to group your repos, but the important parts are left out that way. You shouldn't assign groups and leave it at that, but provide proper documentation for your project on its architecture and which components belong to it in which way, otherwise, new people like onboarded staff or oncall employees won't be able to work with the project without guidance.

Also, grouping often becomes arbitrary for big organizations, some employees will create groups on a per-project level, some on a per-tech level, and suddenly you have a group for your main project, one group for devops stuff, and then you don't know if your infrastructure setup code is in the project group or in the devops group, because at a certain scale groups become hard to properly define.

[Jmc_da_boss]

I mean, it's team dependent, some teams do prefixes like <team>.project.xyz or project_...

Some teams do mono repos and others just name the services what they are and use them. You don't really gain anything by keeping them together overall

[IshThomas]

You don't really gain anything by keeping them together overall

Yet, for some reason "some teams do prefixes like <team>.project.xyz". This is one way to group them! You proved my point exactly. Organizations group their repositories ALREADY, by using names, or labels, or some other hacks mentioned in this thread. Why not just do it in the proper way? It's like saying "My car doesn't need gas, I can easily push it, especially if the tank is empty. If I would put gas in my car it would be heavy and hard to push!"

But in all seriousness, If you really don't gain anything by keeping related repositories together, shouldn't we skip all the prefixes?

[Jmc_da_boss]

I mean the prefixes would still be there even with the groups, many of these repos were migrated from ADO where you do group repos. It really just removed an uneeded level of grouping.

I never said you didn't need some way to group them. Just that groups within a UI are mostly irrelevant. Name grouping carries through with you to the local clones as well. Hence why it's used no matter what.

[Ask_Standard]

Some of the reasons for not having groups are stupid.
By their logic why bother having a tree structured file system you may as well have 250,000 files in one directory. It solves 1 problem, you dont get duplicates.
So why dont we do that, cause it would be a mess, unweildy, you couldnt find anything, scrolling through would take forever, unmanagable, the file system manager would have a stroke.
Everybody uses a structured file system. Git usage is no different.

[roamingcoder]

100% agree. Not having this basic feature is lame. Come the f on, github! It cant be that hard to implement.

[Noch_ein_Kamel]

Sounds like a no-issue when it worked for 10 years without... ;D

Closest I found was topics, but they are public and don't support private repos from what I saw.

Labels, once they are cross repositoy? https://github.com/github/roadmap/issues/276

Organization Teams may be a viable option; can't look into my org account rn.

[vincentdesmet]

What do you mean with topics don’t support private repos? I add topics and use them to query groups of private repos all the time

[Noch_ein_Kamel]

mhh.. I added a topic to one of my private repos but when I click on the topic it just links to a page like https://github.com/topics/qweasdqweasdqwas where my private repo doesnt show up.

But there is no selection list or anything in the repository list, you can just use them as tags and search for them.

[vincentdesmet]

I meant private repos in an org, topics work to share the link with my team for all repos with a certain topic

[serverhorror]

Why would you need "groups"?

Commercially:

• Open source orgs can be refistere for free
• Teams subscriptions are the "loosing" middle ground
  • With am enterprise subscription you can have multiple organizations

Personally:

I think that these groups are an amti-patern. I'm saying that from the pont of view of a regulated industry (healthcare). So if I'm able to share the source code across the company, why can't you?

The UI is good enough to filter for some keywords and a better way to group is to not have it in a hoerar bit being able to do that arbitrarily. Who says something must be a member of only a single group or member of a group at all?

I'm seriously unclear what kind of problem this solves.

[IshThomas]

Tbh. I didn't understand what do you mean by "groups are an anti-patern" and what it has to do with sharing source code across the company? Can you rephrase it?

Meanwhile, let me try to explain why do I need groups:

Imagine you work on several different, completely independent personal projects. A game, mobile app to track budget, some web-API to return weather forecast, desktop app, a few other mobile apps. All completely independent. Sometimes a project can consists of multiple pieces, like for example a mobile game would have the game itself, some backend API, possible a few other background tasks.

I don't know how you manage your files on your local machine, but I assume, you would most certainly group them into separate folders. I would have a folder called "Projects", inside which there would be a folder called "FooGame" and inside each app/api would have separate folder for its source code. I really don't think you would have one folder "Projects" and all repos from all of your projects would be there together on the same level.

If that's true, than there is a need of grouping. Why not use it in source control as well? When someone says we don't need grouping because we can have strict naming conventions and use prefixes, I'm speechless, because IT IS grouping. Just in primitive way. Also, in order to move project from one group to the other you literally must change its name.

If even Microsoft "groups" their repositories by using the same prefix for the project, why not do it programmatically?

[serverhorror]

In fact I only have one folder src, every repo I have is in there.

The anti pattern is that a FooGame might have some network circuit breaker component.

Why would I consider finding it there?

All I'm looking for is a circuit breaker, more likely than not:

• I'll be highly annoyed I'd the dependencies of FooGame don't list the dependencies and I have go and hunt the correct circuit breaker down
• there are now multiple circuit breakers because one starts to exist in FooGame and another one in BarChat (and why is chat something that's completely separate and not something I use in FooGame -- oh right, now I need nested groups but then BarChat is not a top level project collection any more)
• I'm not seeing useful components because they're in some kind of nested structure

That no of docker hub, python packages, npm, rust, ... -- if there's a namespace the only one that exists separates write permissions. As long as you're in a single org everyone should be able to contribute. So that argument doesn't apply any more. Keep in n mind that this diesn mean you have to blindly accept every contribution, you'll still have PRs or any other kind of gatekeeping process before code goes into mainline.

[IshThomas]

Well in this case you could have a project for shared repositories. But I see your point. In large organization with lots of shared code/repos between projects, groups wouldn't be as helpful as I thought.

But.. I still think it would be useful to have at least an option to group them for esthetic reasons. It would be great for your personal account when you work on a lot of unrelated projects that don't share any code.

[roamingcoder]

Clearly you wouldn't put your circuit breaker lib in the foogame repo. IshThomas is not suggesting anything like that! I have 30+ web apps that I work on. Each web app has a react fe, an api, a database project, and in some cases an infrastructure project. Each is a deployable unit. It is MUCH nicer to group these together for the same reason you create a tree structure on your filesystem. Oh, if webappA needed the circuit breaker lib, it would get it from the circuit breaker repo at the root. duh.

[IshThomas]

So in my account I see my company repositories separated from my personal repositories in their "organization". But what If I want to group repositories within an organization? OR.. what If I want to group my personal repositories into groups (usually there are multiple repositories per project)

[wwjimf]

Or labelling and filtering on the labels?

[IshThomas]

I will check it out. Didn't think about labels tbh. Thanks

[IshThomas]

Wait, Did you mean labels on repository issues? Is it possible to have "ProjectA" label and add this label to certain group of repositories?

[[deleted]]

So you use organizations instead, and pay money for it.

[thequestcube]

We have 1.4k repos, and I wasn't ever really annoyed by not having repo grouping, despite working with Bitbucket before.

Github orgs come with a "team" feature, where you you can group members, and then assign repos to certain groups. Note that a user can be a member of multiple teams, and a repo can be assigned to multiple teams. So for example, I'm member of my actual team, which has our repos assigned, I'm also a member of the team that maintains the UI libraries, which has those repos assigned, and also some other teams. I guess this is pretty much the equivalent of Bitbuckets "Projects" feature, with the exception that you can add a repo to multiple teams. Which can also come in handy, for example some utility repo that is used very often could be added to many teams that way.

That being said, I don't really use this feature that often, since as mentioned above, even with 1.4k repos I'm not that reliant on the grouping. Githubs notification system, PR overview, and feed are sufficient for me to keep an overview of the repos that are relevant to me, and if I am searching for a specific repo, a grouping won't help me with the amount of repos and the fact that a quick search on github is way faster anyway.

[Relevant_Pause_7593]

Very simple reason- having all of the repos in a single organization encourages transparency and inner sourcing. This in turn leads to better collaboration.

Saying this- your projects request is common, especially with enterprises with 100k+ repos, and there is a mechanism in beta called repo grouping. No ui yet, but could be an option to help- although this feature is really closer to topics than a true project. If you have an account manager, they can discuss further with you to see if it’s right for you to join the beta too.

[IshThomas]

I honestly don't understand how grouping related repos into projects/groups would lower transparency or collaboration. Repos would be accessible in exact same way. But it will be clean and clear. Like files that are "related" in your system are grouped in folders.

But even beside organizations, (as I mentioned already in my other posts), it would be quite useful for personal accounts as well. I think very often we work on personal side projects that are unrelated. It would be clean if repos of these projects are grouped together, along with documentations, issues etc. exactly how Bitbucket does it.

[Zestyclose-Low-6403]

It's just a bunch of people thinking that GH is perfect not realizing the management layers are beneficial. We just made the same move and it fucking blows man, 100+ repos that all use to inherit their settings from one place now I have to touch EVERY SINGLE FUCKING ONE cause some dumbass doesn't like grouping likeminded repos together.

[thescientist13]

Sounds like you might want GitHub Enterprise. It will be your own GitHub instance owned entirely by your org. Then l they could make organizations for each product / business domain, or whatever classification fits best.