How to partially merge projects through version control?

Question

git

I’ll note right away that I only worked with Mercurial, but I think advice from Git users is also suitable, since the principle of operation is similar.
There are several web projects (sites) on a common code base (self-written cms), which is constantly updated. Unique modules and components of the projects are also constantly updated, everything happens at different intervals depending on the flaws found and the requirements of the projects.
Projects have an engine folder with the same files, a modules folder with mixed files (some are used in all projects, some are unique to a particular project and others have nothing to do with them) and a templates folder, where there is a folder with a project template and a folder with a "default" template - a blank for new projects. All projects are carried out only by me, in the future I hope to connect assistants, but with such a zoo of versions it is still difficult, and so far this is not about that.
Let's call files with code that is used in all projects - "common components" , and files with code that is unique in each project - "unique components" .
Now I have my own independent Mercurial running on each project, just to maintain version history and push to a remote server. In order to transfer common components between projects, I make a comparison and stupidly copy from folder to folder, which is not convenient -every time I have to remember in which file I made updates since the last copy, and whether I corrected something else in that project that I forgot about, which is fraught with killing the necessary code.
What I need:
- to select a base of common components from all projects, without unique ones (except perhaps a default template, so that there is something to base new projects on). - if a unique component
is updated in one project , then it should be added to the commit of this project, but should not affect file changes in other projects. And if a file from the shared components has been updated , then it should become available for updating in all projects.
- the ability to update the entire codebase of common components on all projects at once.
- the ability to create new projects, both on the basis of only a common base and any of the projects, but at the same time be updated further only with "common components", and not drag changes in the project, with a short slope.

This is also necessary, but after, as it is difficult

- отдельным вопросом стоит файл текстовой базы, они должны частично обновляться но при этом сохранять свою уникальность. Пример. Есть фал texsts.php, общий и уникальный одновременно: переменная maintext содержит в себе приветственный текст, который на каждом сайте уникален, но для новых проектов есть заготовка. И тут я захотел добавить новую переменную hellotext, которая будет использоваться в новой возможности общей компоненты (для вывода приветственного сообщения пользователю), но ранее этой переменной не было совсем. Она должна появиться во всех проектах, но при не затереть переменную maintext.
- а ещё надо обновлять структуру базы данных без самих данный, даже не знаю как такое сделать

As I see it for myself:
- I hope that somehow you can take one folder with common components as a reference, and consider the rest of the files that are found in projects as unique components . The prospect of writing a huge list of files to ignore for each project individually is not very encouraging.
For some reason, I believe that the version control system can somehow do this, but I can’t figure out how, give an example, who faced such a situation.
If something is not clear, write, I will paraphrase.

Answer 1

That's right, Subrepository will help you for identical files .
In Mercurial, this is a very interesting thing. The algorithm of work is something like this:
Inside your project, create a folder with a subrepository, for example library, initialize (or clone a ready-made) project of the project's shared library in it:

$ mkdir library
$ cd library
$ hg init

Specify that this folder is a subrepository, for this a .hgsub file is created in the root project and the library is specified there:
You should not forget that you will need to commit library separately from the main project (or specify a special key), and the modified library will fall into the general repository only after a commit in the main project.
If changes to the library happened separately from the project (this is often the case since the project is unique and the library is the same for many projects), get fresh updates without direct pooling ( hg pull) from the library itself is not possible, since Mercurial does not know how to update subrepositories recursively. But for this you can use a little trick, you can explicitly specify which subrepositories need to be updated when updating the main repository, this is done using the [hooks] section in the project's personal mercurial settings ( .hg/hgrc ), for example:
To the .hg/hgrc file we write:

[hooks]
preupdate = ./library/hgsubupdate.sh

And to the hgsubupdate.sh file:
Then, when the hg update command is executed, the subrepositories specified in the hooks will be recursively updated in the main repository.
In new projects, you can simply fork the main repository and maintain it completely separately, and the common sub-repositories will be loaded as well.

Answer 2

About the first. As I understand it, you just need to separate the common code into a separate repository. Further, for local projects, it is easy to do

hg pull http://bla.com/main/baseproject
git pull http://bla.com/main/baseproject.git

hang on and keep working.
You can use aliases instead of full paths. Available in Gita and Mercury
Another better option is Subrepository . Each project has a directory with a base project, and in the main code of the project you use a common code base (include classes, inherit from some base class, etc.).
Choose what suits you best.
Regarding the second question:
You can also give it to the version control system, but it will be difficult to merge when the lines in both repositories are changed.
The best option is when there are three files:
1. Default settings in the base project.
2. Project settings file.
3. Developer settings file.
Regarding the third question:
You need database migrations . This is generally a separate mechanism that is difficult to do correctly, but it is difficult to live without it.

Answer 3

Git submodule

Answer 4

I'm not sure how correct my answer will be, you asked about the version control system, but I would recommend using a dependency manager. If you work with php, then there is composer, which does everything that was indicated in the first question (not sure, really about other languages). On the other two points, I join @maxaon

Answer 5

Did the author come up with a solution? There is a similar question.