Multiple projects in one repository GitHub

Question

I have 5 java projects working together. At first I was working alone on these projects. Now someone joined me and we actually need to use GitHub to work efficiently.

Project A is let's say the master project it doesn't depend from any others. Project B is depending from project A. Project C is depending from B and A. Project D etc etc.

I'm facing a design problem:

Should I use one git repo and put all of them together but in different folders? Should I use different git repo and keep them independant (might be better for commiting)? Should I use different git repo and regroup all of them in a single master git repo?

Thanks in advance for your help.

Answer 1

You should put each of them in its own git repository.

You then can use git submodules to add depending project to another.

Example: Project A will contain project B as submodule.

Read more about git submodules
Official documentation

Answer 2

In fact your question could be summarized as: should I use a mono-repo approach or a multi-repo approach?
That is broad subject but to make things simple: it depends on the coupling level and the life cycle between these projects.

You want to use a mono repo approach and add multiple projects in if these projects are designed to live and evolve together. For example, if only these projects have dependency between them and that when you change a dependency you will change the consumer, you have clearly no value to split out them in multiple repositories.
It will make global source code readability weaker and commit/pull/request/merge on multiple repositories for a same use case, which makes their readability and their consistence weaker.

You want to use a multi-repo approach and to have a project by repo in if these projects are not designed to live and evolve together. For example, if some of these projects are used by other applications than those you quote, you have no value to couple the project dependency inside the repository of the consumer project because there are other consumers, so why that consumer and not the other one?

You have also the super mono repo approach such as that one used by Google or Facebook that adds all projects (or almost) in the same repository, whatever the level of coupling between projects. Doing such a thing is not simple and demands to custom finely the CDCI and the SCM tools to keep things practical and simple in spit of the repo size.

Answer 3

This thread can give you the right answer of how to organize the project, but remember that it will only be an opinion based answer as there is not the best way to do it.

Answer 4

Apologies as it's not that concrete solution to it but it does the job, what I tried is I had a situation where for some reason I had to add all the projects to one repository only so I followed the following steps:

1. Create a new repository with the main branch (Keep it Empty)
2. Create a branch from Main (Empty) with the respective project name (Create as many as branches you want with the respective projects you have)
3. Then Checkout to that branch with the command:

$git checkout -b <branch_name>

4. If the origin is already there then remove it first then add the newly created remote origin with the following commands:

$ git remote rm origin  (To remove remote origin)

$ git remote add origin https://github.com/<USERNAME>/<REPO_NAME>.git

5. For authorization of the operation you need to use the following command:

$ git remote set-url origin <Access_Token>@github.com/<USERNAME>/<REPO_NAME>.git

6. Now, you can push the code and files to the branch directly by the following command:

$ git push -u -f origin <branch_name>

7. If the above command is throwing an error then try first adding the files by the following command and then try step 6 again.

$ git add .

This worked for me, as whenever I want to change/pull something in any project I just clone a specific branch make changes in it and then push the changes to that specific branch only. This way you can have multiple projects under one repo. I tried this solution by myself only to bypass the tricky way of Orphan branches or having multiple Repos.