GitHub, a website where more than 2.1 million organizations store their Git repositories remotely, is a great free resource for any programmer. I personally use GitHub almost every day to manage my code, collaborate on projects, and contribute to open source. GitHub is a powerful platform where programmers can easily work together on the same file of code without creating confusion.

Nothing is Perfect

However, GitHub lacks one thing. And that thing is extremely significant, as it is the single greatest feature of GitHub: repositories. While GitHub provides a plethora of tools when managing repositories inside of them, it doesn’t really provide any means for organizing them. For example, I would really like a feature where users can create directories within their profile to organize their projects.

Before we continue, I want you to know that I don’t think GitHub itself sucks. However, repository organization is a feature that users have been requesting for almost a decade now, and it would really be nice if they added it to GitHub. After all, they’re pushing all these new updates with GitHub Actions and Sponsors now. How hard would it be to create an update with folders for your repositories?

Why is repository organization important?

When I use GitHub, I use it for two main things: Projects, and contributing to other projects. First, I’ll talk about my GitHub projects.

Pretty much everything I write is hosted on GitHub. While only a fraction of those projects is public, the rest I still access quite frequently. I have many different types of projects on my accounts, such as web applications, games, android applications, and some small projects that I use to automate tasks and such. It would make my life a whole lot easier if I was able to categorize those projects into subcategories, instead of having them all in one big clump.

Imagine being this guy on GitHub. With over one thousand GitHub repositories, I would go crazy having to sort through all of them to find one.

I understand that you can sort your repositories based on whether they are forks, private, or mirror repositories. You can also classify them by programming language. However, this is not enough for me. Pretty much everything that I write is either in Java, Python or Javascript, so the language feature doesn’t help much. Also, I have no customizability option on how my repositories are classified. They all kind of just sit there.


My GitHub Forks

As a programmer, I often contribute to open source projects. Many of these projects I don’t have commit access to. Therefore, I need to create a fork and merge my branch with a pull request later.

Some of these projects I contribute to only once. This creates a plethora of forks on my GitHub profile of projects that I don’t even actively contribute to. This just adds to the number of repositories I have to sort through to find the one I’m looking for.

To solve these problems, I’ve put together a hacky solution, but by all means, this can’t be the best way to organize GitHub repositories. What I do is basically create organizations for my GitHub forks and GitHub pages, which helps relieve my sanity a little bit. However, with organizations, I can’t create private repositories without paying for a premium plan, which really sucks when I want to upload some project that I’m not ready to open source.

The Solution

Literally the one thing GitHub would have to do to fix this issue would be to implement a folder structure for repositories the URLs of the repositories don’t have to change, the folder structure could be merely for organization within the user interface. A user should be able to create and delete folders, move repositories in and out of folders, rename folders, and maybe organize the order the folders are in. Is that too much to ask?

If anyone from or representing Github is reading this article, I would really appreciate it if they implemented some sort of folder structure for me to store my projects in. I appreciate all the features that GitHub provides me access to as a student, but this basic feature almost seems like it would be standard on a platform like this.