multi-product architecture, with large common part

Question

my company develops one "main" product - web application, where users:

• upload files
• download reports based on those files

All of this is done with Postgresql database, Python3 backend and Angular/CSS/HTML frontend, split into few docker containers.

The problem is that we have few different products (currently 3, but the number is expected to grow) that share about 95-99% code, but have some important product-specific differences. Such differences might be:

• different set of reports available
• different set of accepted input file types
• different user accounts (e.g. approach to "i forgot my password" request)
• Possibly much, much more

Differences could affect every part of the code (database/backend/frontend). Some of the problems might be solved by clever configuration files. Some with dedicated modules, or so, but - as there are almost infinite possible modifications between products - we started to look for a more general solution, such as:

1. Never-merging git branches. We would have branches "base", "product_x", "product_y" etc, common development would be done in "base" (merged further into all product_* branches), product-specific development would be done in product_* branches.
2. Product-specific directories + some clever building. The simplest solution would be "code for product X is everything in base directory, overwritten with all corresponding files in product_x directory"
3. Completely separate repositories, code would copied from "base" repo to product repo when needed.
4. (+ few more more-or-less stupid options).

Every solution we could think of has serious downsides. So, the questions are:

• how would you do this?
• what should we google/read to make the best decision?

We are aware that there probably is no perfect and painless solution, what we are looking for is a solution that will not become terribly painful in a year or two : )