82

Here's the situation: I'm migrating a bunch of repos to github. The repos are currently organized into groups/directories like 'stack', 'websites', 'applications', etc.

There's no way (I've found) to create groups or folders on GitHub for repos, except with organizations, which seems a poor choice. But maybe not? The problem here is that some of the groups are very small, while others are large... with sub-groups, and I'd like to keep all the projects in one root bucket.

So, I'm left with maybe using a naming convention. Like: 'stack-apache', 'website-foo.com', 'application-some-project'. Or just giving up on organizing them in github and let the project pages / website handle the organization.

Re. scale, I'm looking at 20+ repos initially, with new repos added over time at an estimated rate of 2-5 /year for the next few years.

Anyone have experience with this kind of thing?

zanerock
  • 3,042
  • 3
  • 26
  • 35
  • 8
    Meta observation: I'm pretty sure searched for answers when I posted the question (because I always do). Likely I never used the term 'folders'. It is, of course, mostly a duplicate. Also, brings to mind something I once heard about the difference between "movies" and "cinema". They're synonyms, but not the same. Different cultural groups use them in different ways. This makes me think of the positive aspect of duplicates in that they make things findable because it's putting out a slightly different take/way of thinking/perspective. – zanerock Mar 14 '19 at 17:45
  • 2
    Yes, that is the primary reason why duplicates are usually still accessible and readable on SO. – Marvin Aug 12 '20 at 21:04

3 Answers3

46

Update 2023

Github added the lists-feature (still in beta). If you star a repository you can add it to an existing list or create a new one. Still not a very intuitive way to group your own repositories but it works. list selection

starred lists

Update 2020

I'm not sure exactly when, but Github has (somewhat recently) added the concept of projects, which kind of fill the missing gap. I would argue they aren't quite the same as Bitbucket Projects but they are better suited to grouping related repo's in Github than Orgs

enter image description here

Original answer

Organisations in my opinion fit a different purpose in Github than grouping repos (although they do serve to group repos). Organisations are more about fine grained control around repo access (thats my understanding).

Bitbucket has introduced the concept of "Projects", with the following hierarchy (with a comparison to Github):

Bitbucket: Team         -> has N -> Projects -> has N -> Repos
Github:    Organisation -> has N                      -> Repos

Bitbucket still allows Repos to not be assigned to an team or project, I am guessing to support older repos that existed before the concept of a project.

To answer the question, no, not directly. There are outstanding requests with Github to add groups, but it doesn't seem likely (at this point in time).

Prefixing works as a so-so solution:

Repo name: [project]__[repo name]

Lets say you have a client "acme" with two repos:

Eg: acme__api Eg: acme__landing

Github's search is quick and inline, so doing a search for acme__ in your repo list will list all repos for the acme__ project.

JohannesF
  • 30
  • 7
Chris
  • 54,599
  • 30
  • 149
  • 186
  • The one big problem on the github for me was losing everything assigned to a repository after delete a repository. Yes, forks will be lost because of hashes in the git, but what about all other stuff? It's quite very annoying when you use github only as a mirror and lose all related data when recreate a repository from another storage. – Andry Jun 06 '20 at 12:33
  • 44
    GitHub projects are more to manage workflow in a kanban style way, not to group repos like GitLab does. – mcamurri Sep 03 '20 at 09:10
  • 5
    @mcamurri Agree 100%. It "kind of fills the missing gap" – Chris Sep 03 '20 at 10:36
  • 1
    It still doesn't enable me, as a user, to group repos that aren't mine for purposes of organization and separation - repos of e.g frameworks, or tools – Gal Grünfeld Dec 28 '20 at 21:20
  • @GalGrünfeld Agreed - its still not a fully solved problem at the Github end – Chris Dec 28 '20 at 23:36
  • Can you put the updated part in the beginning of this comment? – Saba Nov 30 '22 at 17:37
  • @Saba I don't understand, what do you mean? – Chris Dec 03 '22 at 13:38
26

The idea really is to use organizations to group your related repo together. This also makes it easier for your team member to filter their activity feeds to only organizations they're interested into.

This is like that on Github as git is repo based, not file system based like SVN.

Maybe "Organization" is not a very intuitive name, but on alternative Git platform like Gitlab, these divisions are named "group". You should really consider them like that.

Simon Boudrias
  • 42,953
  • 16
  • 99
  • 134
  • Sounds reasonable. I originally had 'Or maybe "Organization" is a misleading name?' in the post, but cut for brevity. I think I'm going to go with core projects under the company-Organization and create a few group-Organizations for organizing related projects. – zanerock Jan 04 '14 at 16:11
  • 65
    I'd argue that treating GitHub organizations as groups complicates billing and permissions and fragments management. GitHub simply does not have a concept of related repositories without imposing additional semantics. Prefixing repository names is the most common practice I've seen. – Emerson Farrugia Nov 16 '15 at 11:29
  • Good point re. billing. Unstated, the original question was for fundamentally open source projects, so billing wasn't an issue. My feeling is that the 'teams' is sufficient to organize permissions, so in an open source context, this works. In a closed source context, I agree re. prefixing. – zanerock Mar 10 '16 at 21:59
  • 1
    the unfortunate addition to this is that whilst organisations are the way to create this. They exist as a top level entity. So I can't create an organisation inside my account so it appears like a group, they attach directly to the github.com top level namespace :( – Christopher Thomas Apr 14 '19 at 17:55
7

I think, the idea to group repos on the github is that just put a delimiter between items you want to be related to each other. For example, "project1_projectA_projectX", or "project1-projectA-projectX", or even "project1--projectA--projectX".

For myself I prefer the double-dash delimiter as more intuitive for replacement of the slash character delimiter (/) and less usable in a standalone repository name.

Then the list of your planning projects you have to create would be:

  • project1
  • project1--projectA
  • project1--projectA--projectX

As soon as you create a repository with a delimeter (_ or -) in your name, there is won't be an option to set, for example, the repo description or license from the repo title page. You have to handle these from the repository title page after a first push has made. But you can leave it simple, for example, for the projectX it would be something like this: "project1--projectA submodule".

Andry
  • 2,273
  • 29
  • 28