Create groups of repositories

[jackrdye]

New feature - group repositories (categories)

Currently I have many repos. Some are projects from university others personal, and some more serious.

I would like to be able to group my repositories

I.e. create a group where I can put all my demo projects in

I feel like the list of repositories is quite cluttered and could use some more organisation. I only have 9 repos at the moment but I can easily see this just getting more chaotic as time goes on.

If you could make this a feature that would be awesome.
Thanks :)))

[jdevfullstack]

well as for now, we have Orgs that you can use to group your projects, you can have an Org without members, it's just to organize your repos plus you have different domains that you can use for your custom domains without conflict with your personal account

https://docs.github.com/en/organizations/collaborating-with-groups-in-organizations/creating-a-new-organization-from-scratch

[drLis]

Not sure, that it's a optimal solution. Can I create sub-orgs and sub-sub-orgs like groups in Gitlab? It takes me for big difficult projects, which for example contains groups of repos like SDK-repos, template-repos and other.

[dipakparmar]

• If you're on the paid plan then you will have to pay for all the other orgs you create. It all comes with additional maintenance. I think some sort of Project structure would be nice. Currently, there is a teams feature in Github, which solves some of its needs.

[KnightChaser]

Just organization is not a good approach. Treating the repository group as a GitHub organization may cause inconsistencies in access, billing, and other organization-related policies and many inconveniences.

[yhojann-cl]

I understand but I think that an organization is to create an organization, not to group projects, for example, an organization needs to create groups of projects per solution, do you say that an organization should create multiple organizations per project? What happens with user management? You would have to manage all the configurations separately. I think that the organizations function does not work to group projects since it is not designed for it.

[EdWordy]

I think this "category" feature would be ideal, especially for solo developers or for freelancers who don't wish to create an organization (as suggested by @jdevstatic).

Otherwise the repo section of a users profile is little more than an ordered list, rather than say, something like a more complex hierarchy represented as a timeline or chronology of work history/overview of projects undertaken i.e. a format that acknowledges how messy, or clean, development can be (at opposite extremes).

[miguel-rodriguez-cimino]

This is such a simple feature I cannot imagine why it doesn't exists in the first place. Organizations are nice, but as other people mentions they don't have a hierarchy. Plus, they come with a whole bunch of settings and additional stuff that I don't need nor want to care about. For all practical purposes creating an organization it's like having yet another account to manage.
I have to resort to practices like name conventions for my repos so I can keep track of which ones are related.

[GabrielDeNobrega]

It also surprises me that GitHub hasn't implemented a feature like this yet. I'm not even close to being a proficient programmer, but I can imagine that this wouldn't be too difficult to add. There's undoubtedly a substantial number of people who have been requesting this particular feature for years, and it seems that it hasn't been given a high priority.

[petatemarvin26]

Additionally if you were working with Microservice that per service has its own repository and you don't want to messed up by searching and looking for the other services related to the project, especially to those community contributors who has tons of repositories,

and the Organization feature, what if I have multiple organization and each organization has different unrelated group of repositories how would you think it looks like, it will be more messy of course, that is why we proposed Group of Repositories, and it will be very more significant for developers who deals many projects

[JorgeSivil]

This is so basic that I find myself very confused as of why this is not implemented.

If I have a big organization, and have different teams, products, I would like to organize their repos in different groups, and give them access to all those repos in the group, for example.

[4S1ght]

That's actually a perfect point. The ability of grouping repos alone would streamline things a LOT.
I recently started a project that was too big and too messy to build as a monorepo, so I decided to split it into multiple libraries that are just glued together inside the "core" project repository. I had to create an entire organisation for it just to have them grouped, this is ridiculous.

[daviddomkar]

I also came across this limitation. In my company, we use GitLab, where this is a solved problem. I would like something similar in GitHub, I work on a side project where I have lots of different repositories for frontend stuff, microservices, and libraries. I would like to have separate groups for all of these because it is really messy to find what I am looking for just in the list of repos. And yes, I have a GitHub org just for this project. But grouping within the org is what is needed.

[Waterstraal]

In dire need of this as well...

Alternatively instead of a single category, the ability to add one or more labels to a repo would be good too. This way you have a little more flexibility as you can group repos in more than 1 way. Then add a label filter to the overview and we're good to go 👏

[rogerweb]

the ability to add one or more labels to a repo would be good too

GitHub already supports it. They call it "topics".

[Waterstraal]

And the new Lists feature kinda works too. I just would like to have a dropdown or hierarchy on the overview

[Anoesj]

Lists are public, whereas I'd like my repo groups/categories to be private.

[Julynx]

I would love to see this feature added!

[KarlsMaranjs]

This is a long requested feature. Think about this case. I have two different projects inside the same organization. Each project containing multiple microservices. As of now, the only alternative is to create two different organizations. Maybe back in 2007 it was pointless, but now, when the average app has at least two separate repositories it is essential to organize them in the same organization.

[riccardo-bernardini]

Let me add my voice to this thread too. I teach DSP and I want to share with my students demos, libraries and other stuff. Having categories would allow me to create a, say, "Teaching DSP" top level group and then, underneath it, "demos," "libs," and so on.

I decided to use GitLab because it has this feature.

[Krowso]

Use a local gitlab server at the company I work at and its had the ability to organize repos into groups for quite sometime now. So I'm kinda shocked github hasn't added their own version of the feature yet. Would love for it to be a thing.

[kvedula18]

can't believe such a basic feature is to be requested, considering all other tools provide it. bummer !! I'm leaving..

[tzoratto]

As of today, I can see 2 different ways to group repositories:

• using topics, as already mentioned up above
• using teams

Teams are not only groups of people, they can be used to group repositories together and can be nested. Great insights about this in this gist.

I'm curious to know the reasons why it hasn't been mentioned here before, as from my understanding, it seems to be the way to go (instead of using organizations which are not meant to group repositories, as per the official documentation).
I'm also interested in other ways to do so, if anyone knows one.

[Krowso]

I feel like topics are more of a tag/label kinda thing which is useful for filtering and helping with searches. Not actual group containers.

One of the problems with organizations (for me at least) is that it requires me to use an email just to create an org which is then publicly displayed. I'd rather not expose my email or create an extra one just to create an org. Plus, i think a group feature would be more ideal for solo developers.

Also based on the documentation it looks like an org has to be created just to use the team feature. So your statement in the second paragraph about using teams instead of orgs doesnt make sense, unless I'm misunderstanding what you are trying to convey.
https://docs.github.com/en/organizations/organizing-members-into-teams/creating-a-team

[tzoratto]

When I said that organizations shouldn't be used to group repositories together (generally speaking), I meant "multiple organizations". Of course you still have to use one organization, but then use teams inside it to organize repositories in some ways.

I get your point about the topics, but that's more of a technical point of view I'd say. I mean that you did not describe what you can do with actual group containers that you cannot with tags and/or teams.

To be honest, I am a bit confused about all this. Even though, by habit, I was also looking for the group feature when I started using GitHub, I'm still not sure whether having actual repository groups would change the UX in a noticeable way or not compared to the use of tags and teams.

[Krowso]

Gotcha, I understand a little better now what you are getting at.

At least with my experience in my company's gitlab it does provide a nice directory style way of viewing groups and the repositories or subgroups under them. As far as UX goes it's probably nothing special, for me at least it's just a case of what I'm used to.

My big issue is still the email thing, which gitlab groups does not require.

[mlisowsk]

I am seconding @tzoratto suggestion to use GitHub topics. I prefer the tagging way of organizing information as it's way more flexible than a (hierarchical) grouping/folder way. Now we just need a user interface to actually leverage these topics.

• Let us search for a topic in the repo search bar (e.g. "topic: jquery", or a clickable collection of topic labels that occur in my repos)
• Display virtual folders of topics (several levels deep as we can have more than one topic) - this will satisfy users who asked for "grouping" and will help those who prefer a "browsing" way of searching
• Give us an easier way to assign topics to a repo (other than opening the repo, go into settings, type the topics, save)

[Waterstraal]

I don't care which implementation is chosen as long as you can have a wiki, issues, projects and rbac on the group level. I don't think that a topic would work for that reason as they feel a bit more fluent to me. But I'm sure that can be resolved with some GUI tweaks.

[albfan]

gitlab just offer infinite subgroups and they can be private.

Shouldn't be that hard to implement:

• Allow private organizations (top group)
• You might want wikis, repos, issues on your org: Just thinking about a typical structure:
  • Website group
    • forked dependency
    • website code
  • App group
    • Android subgroup
      • library code
      • App code
    • iOS group
      • library code
      • App code
  • Server group
    • code
    • wiki api documentation
  • Desktop group
    • code
    • manuals, guides

what is the vision to not implement this, or reason that makes it impossible, the workaround looks like create fake repositories that collect in README related repos, which is really weird.

private orgs with infinite suborgs (subgroups sound way better) should just solve this, any chance?

[inc0der]

It's the only feature that is keeping me from fully commiting to GitHub. If this is ever introduced you can expect my money every year with all of my projects migrated over.

[ZA1NZAFAR]

+1 to keep the hopes up!

[anonbcp]

+++++++++

[irdcat]

+1
I'm planning to make a multi-repo personal project, but at the same time I would like to keep all of my personal repositories on one platform.
Judging by the fact for how long people have been asking for such a basic feature, I'm seriously considering moving completely to Gitlab.

[D14rn]

wake me up when this is a thing please...

[KnightChaser]

real

[benvonh]

setting alarm for 2028

[tokky01]

++

[tzoratto]

Come on guys, you all know that "+1" messages are counterproductive. All you'll manage to do is making people unsubscribe...

[thebluetropics]

please add this feature

[Blackxes]

For gods sake please stop commenting on this Issue except its something new or important to mention. I know I brake my own saying with this comment but all you guys do is make people unsubscribe since every single person subscribed to this Issue gets an email every single time someone posts a comment.

So please use those easy to press arrows or anyother reaction underneath a comment to show your interest and refrain from writing a comment

[insidesecurity-yhojann-aguilera]

For gods sake please stop commenting on this Issue except its something new or important to mention. I know I brake my own saying with this comment but all you guys do is make people unsubscribe since every single person subscribed to this Issue gets an email every single time someone posts a comment.

So please use those easy to press arrows or anyother reaction underneath a comment to show your interest and refrain from writing a comment

People continue to write in the hope that one day this request will be heard, but at the same time this is the main problem of this thread of conversation: being heard.

Many other users like me need to use project grouping just like all other repository management platforms do, but who listens to our requests? Is there someone officially collecting this? Is there any planning for this? Has it at least been considered officially?

I understand that this is an open community about GitHub topics, and it is just a community, not a system where they can officially listen to you, there must be more direct communication channels but most people just search on Google for how to create project groups and the first result is this thread.

Github has stopped innovating for quite some time now, and for this reason I doubt that features like this and others of similar importance will ever be implemented.

For now, it is enough to sit and read how every day more and more people arrive asking for the same thing endlessly.

[tzoratto]

Still, companies with hundreds employees and repositories manage to handle them just fine using:

• Terraform
• GitHub teams
• Organization level settings such as repository rulesets
• Topics

After almost a year of GitHub usage (having set up all the things mentioned above for such a company), we don't feel the need for repository groups even though I was looking for this feature at first.

My point being that as any other software vendor, GitHub has a roadmap and so many new feature requests that they have to prioritize. While you, and many others from this thread, see this feature as a major one, you (and all others from this thread) are a small percentage of GitHub users, and chances are this feature is not requested by the majority of users and company using GitHub compared to many other features.
Giving feedback of why you would need such a feature is useful and productive, and it has already been done in this thread, but saying that GitHub doesn't listen to their customers and doesn't innovate anymore, just because the features you'd like are not being implemented won't get you anywhere.

[igorkutsybin-sodastream]

bump

[simone-boa-ideas]

This is a much needed feature and it has been requested for a very long time (see https://github.com/orgs/community/discussions/4837).
Could we have an official answer on this?
As said by multiple people, managing hundreds of repositories in the same organizations or microservice architectures with the current approach, it becomes very impractical, very fast.
Thank you

[mcaxtrzen]

That'd be an awesome feature to have!

[MKL-SebastianLoeffler]

As organization admin with dozens of repositories I need categories WITHIN the organization where I can group repositories for all members of the organization.

[dremnik]

This definitely should exist. Makes organization of related modules and team coordination significantly easier.