What is the correct way to develop multiple branches in git?

Question

git

Good afternoon. There is a project on github - https://github.com/chuikoffru/rrbe
There are several possible areas of application: developing a landing page, layout of e-mail letters, and creating editable references. In different areas, different capabilities of this editor are needed, but the core of the system remains the same.

How to organize work in git with this repository, and maintain several branches: for example
master - main branch (the core includes drag'n'drop, context menu and basic editor hooks and features)
web - core + features for landing page
email - core + features for
word letters - core + features for references

Accordingly, when I fix something in the core (the idea is to create a separate branch based on the master for each fix, do I understand correctly?), I need to distribute it to other branches, preferably automatically, but it can also be done manually (the question is how? git rebase / fetch or something else, the main thing is not to overwrite the features in other branches, but to apply only fixes)

And yet, when I push a new branch to a remote turnip, github offers a compare & pull request, but I don’t seem to need it. Maybe you need to create separate repositories for each application? Then how do I organize the synchronization of fixes between reps?

Answer 1

This is fundamentally not the correct idea of ​​using a repository. In this case, you need to have a separate repository with the core and several repositories with additional. functionality. That is, 1 project = 1 repository.
You can connect repositories either through git modules (but I don't like this method), or with any convenient package manager, for example, the same npm.
Branches are needed only for temporary development and subsequent infusion into the master

Answer 2

It is possible not to separate the code from the repository into branches. Conceptually it sounds like these modules are dependent on the kernel. All 4 modules (including the core) will coexist in the master. The idea is that the core of the project usually needs to be kept as up to date as possible, and only by keeping it in the neighborhood can this be achieved without problems.
The solution via submodules will require the creation of 3 additional repositories, and having separate branches can get in the way, since it is possible to forget to merge or cherry-pick changes from the master with the core.
Also, master is what the developer sees as the latest working code (maybe not stable, but still). If you have only the kernel there, it may cause confusion where to get the modules. In this case, I recommend that you clearly describe your scheme of working with the repository in the documentation.