Hey there! I've been searching high and low for an answer to this question, but unfortunately, I haven't found anything remotely similar.

I mainly develop small console applications for the OpenComputers platform using Lua. Occasionally, I also use Python to move the application logic from the game to hosting when needed.

On average, my projects consist of 30 to 1000 lines of code, with around 300 lines being the norm.

Now, here's my dilemma: I want to upload all my projects onto GitHub, but I feel like creating separate repositories for each small project would be impractical. So, I've come up with an idea of having one large, shared repository specifically for the OpenComputers platform. Each folder within this repository would correspond to a different independent project.

Do you think this goes against the principles of Git/GitHub? Could there be potential issues with such a repository in the future?

Oh, by the way, just to clarify, I do have other projects besides those for OpenComputers. I plan on uploading them separately to their own repositories.

By the way, have I mentioned that I'm new to Git and GitHub? I would greatly appreciate any advice you could give me!

Your idea of having one large repository with separate folders for each project is definitely possible in Git and GitHub, and it's commonly done for managing related projects or components. It can help organize your code and make it easier to maintain.

However, there are a few things you should consider before proceeding with this approach:

1. Repository Size: Keep in mind that if you have many projects and each project has a substantial amount of code, the size of your repository may grow significantly over time. This can make cloning and working with the repository slower, especially for users with limited network bandwidth.

2. Project Isolation: If you need to share or collaborate on a specific project with others, having an isolated repository for that project might be more convenient. It allows for clearer version control and easier collaboration, especially when multiple developers work on the same project simultaneously.

3. Project Dependencies: Check if your projects have shared dependencies. If they do, managing dependencies within a single repository can become challenging, as changes in one project might affect others. Separate repositories can provide better control over dependency management.

That being said, if the projects are small and not highly interconnected, using a single repository with separate folders should work fine. Just ensure that each project is contained within its own folder and has its own commit history. You can use subdirectories for each project and even create a separate branch for each project to further isolate changes.

Remember to also follow best practices for creating commits, branches, and merging changes to keep your repository organized and maintainable.

If you have other projects besides those for OpenComputers, it's a good idea to upload them separately to their own repositories. This will make it easier for others to find and contribute to your code, and it keeps things more organized.

Lastly, as you mentioned you're new to Git and GitHub, I recommend exploring Git tutorials and GitHub dоcumentation to familiarize yourself with Git's powerful features and best practices. This will help you make the most out of version control and collaboration in your development workflow.

You can safely proceed with what you want to do, which is known as a mono repository. However, it's important to note that there may be challenges when multiple independent teams work on it simultaneously and when it becomes excessively large in size. Additionally, the need for independent releases of different projects may arise. Fortunately, in your particular situation, these potential issues are unlikely to occur, so you can confidently move forward.


Mono repositories can be valuable for managing codebases, especially when multiple projects are closely related or share common dependencies. They promote collaboration and streamline workflows by centralizing development efforts. However, it's crucial to properly coordinate and communicate among teams to avoid conflicts and ensure smooth operations. Regular maintenance, versioning strategies, and clear release processes are key to successful mono repositories.

Consider using submodules to organize your projects. Instead of having one big repository, create separate repositories for each project and have a single "collective" repository with multiple modules. This way, each project can function independently, yet if you ever need to clone all the projects simultaneously, it can easily be achieved with a single command.

Using submodules provides flexibility and modularity, allowing you to manage projects more efficiently. It also simplifies collaboration by providing a centralized point of access for shared modules across multiple projects.

Creating separate repositories for each small project also provides flexibility in terms of versioning and collaboration. It allows you to have specific commit histories and branch structures for each project, making it easier to track changes and manage contributions.

However, if you still prefer the idea of having a shared repository for all your OpenComputers projects, you can consider using folders or submodules to organize your code within that repository. This way, each folder can correspond to a different independent project.

Potential issues you may encounter with a single large repository include increased complexity, slower cloning and pulling times, and difficulty in separating individual projects when they grow in size and complexity.

As a newcomer to Git and GitHub, it's great that you're seeking advice. Remember to familiarize yourself with Git best practices, such as committing regularly, writing meaningful commit messages, and branching effectively. Additionally, explore GitHub features like issues, pull requests, and continuous integration to enhance your development workflow.

consider regarding your dilemma:

1. Collaboration: If you ever plan on collaborating with others on your projects, having separate repositories for each project can make it easier for others to contribute. They can clone or fork the specific repository they want to work on rather than dealing with the entire shared repository.

2. Testing and Deployments: Having separate repositories can also simplify the process of testing and deploying individual projects. You can set up automated workflows and hooks specific to each project without affecting others.

3. Dependency Management: If any of your projects have dependencies, managing them within a shared repository might become challenging. Separate repositories allow you to manage and update dependencies independently.

4. Continuous Integration/Continuous Deployment (CI/CD): If you plan on implementing CI/CD pipelines for your projects, having separate repositories can make it easier to set up automated build and deployment processes specific to each project.

5. Modularity and Reusability: Keeping projects separate allows for better modularity and potential reusability. You can extract reusable components or libraries from one project and use them in another without tightly coupling them.