How to organize a Git repository structure for multiple overlapping projects?

Question

git

We decided to switch from SVN to Git, but the question arose of how to organize the folder structure and repositories. Previously, there was one large SVN repository of the “svn_repo” type, it contained all sorts of rubbish at the root, including binary, but which also needs to be kept in CVS and top-level packages like “com”, “ru”. Inside these packages, there were folders with source codes or third-party libraries (like com/adobe/graphics) or our projects (like com/%company_name%/%project_name% or com/%company_name%/%some_general_self-written_utilities%). By the way, in the project folders there was not only code, but in general everything related to the project - xml-ki, graphics, music, etc. Thus, it was possible to take either the entire repository with all projects, or a specific project (svn_repo/com/company_name/project_name). It's important here
In Git, it’s as if you can’t do this (ideologically), it seems that each project needs its own repository, but then it’s not clear how to “seat” 2 projects side by side and a daddy with the source codes of a common utility for two? You can create three repositories for this (which already store the folder with the project in themselves), and turn the folder structure (starting with com / etc.) by hand - but this is somehow wild, in my opinion. You can probably somehow do something with the help of "submodules", but it seems to be the same again.
How does it usually look like? Is it ok to make 1 big repository like the old "svn-repo"? Will this cause issues with the size of the repository in the future? Is this correct from the point of view of Git's ideology? Or maybe we initially had the wrong approach with SVN (we did it intuitively, when there were more than one project, everything suited)?
Thank you.

Answer 1

As far as I understand, you have java. And even if not she, the thought will remain the same. In fact, the "intersection" of projects is the dependence of some modules on others.
Managing dependencies using a version control system is fundamentally wrong, because specialized tools have appeared for this for a very long time. In the case of java, this can be, for example, maven.
Thus, it is worth storing each module in a separate repository, and resolving dependencies using tools created specifically for this.