How to organize joint development of several projects in git?

Question

git

There are several projects. Each project is made for its customer, and all projects have a core, modules and specific settings. Each customer gets their own modules, often the modules go to several customers, some of them for everyone, some - strictly individually.

Project 1 (core module1 module2 module3 module4 module5)
Project 2 (core module1 module2 module6)
Project 3 (core module1 module4 module7)
Project 4 (core module2 module3 module4 module8)
Project 5 (core module1 module9

) ensure
a) joint development of all common parts (kernel, common modules)
b) prevention of code from one project to another

ps can be subprojects, but I do not want to allocate a separate project for each customer or for each module.

Answer 1

Make a separate repository for each module, store the kernel in a separate branch of the repository for the module.
It turns out that developers developing a common module will have only this module.
Developers developing the kernel (as I understand it, it is individual for each pair of modules) will only have access to the kernel of the modules.

Answer 2

1. For the common parts, we create a separate repository and use some mechanism to deliver the assembled modules. (for C#, for example, this would be a private nuget feed).
2. For each new ordered project - a new repository to which modules are connected.
3. For each new module (if reuse is supposed) - a new repository.
If you have problems with working with a large number of repositories, merge the core and modules into a monorepo.
To connect one repository to another - you can use the git submodules mechanism, but this may cause problems
PS: I would like to clarify what is meant by the project, the core, and the modules. And on what stack of technologies the work takes place - then I can suggest specific technologies with which everything can be simplified.

Answer 3

Project, kernel, and module sources are one thing. Business projects for which we collect builds from the first ones are different. Git is a source code version control system, it's not about solving business issues. Therefore, it is not worth solving questions through git to whom which modules were sold.
If you look more broadly, then let the developers write the code (in one turnip, in several turnips: the core and modules, as you prefer). And in what form to assemble the build for the next customer, let other people decide and do it (and even if they are the same, it’s still within the framework of a completely different process).

Answer 4

Each project has its own git rep with submodules (core + modules)
Development in all reps is carried out according to the gitflow methodology: master (or release), develop branch (is the parent for the master), feature branches (active development of features, fic, etc.). From fichavetki to developer, check, merge into the master. Only turnip masters leave the customer!
The main thing is to correctly divide into modules! And you probably have to follow this moment: a feature was added to the module that requires the core to be fixed. It is necessary to make sure that the module and the kernel match before deploying! On 5+ modules, doing it manually is already so-so!
Good luck!

Answer 5

colleagues!
to all who advised to divide into modules: not an option. I immediately wrote about it (although I called them subprojects).
too many hemorrhoids. To add a file with 20 lines, I need to create 2 new turnips. but the charm begins later - for example, the kernel is obtained in 100500 copies (its own in its local project).
after a careful study of the git, I found the solution most suitable for my task is sparse checkout
ps and for distribution, I decided to use multiple repositories for 1 project (specifying --git-dir).
those. if necessary, deploy a specific project (through git, and so that the "left" code does not get to the customer's server), I'm from the working sparse checkoutmake repository .git-"project name"