How to release features into two branches at once?

Question

git

Goodnight!

What story. We use the following branch system in our project:
- Production (Release version of the project, with auto-deploy to production after merging the code with staging)
- Staging (Test environment where features are released with auto-deploy to the test server)
- Feature branches (In which work takes place ).

Actually, the project lived perfectly on this structure until the moment when the production version had to be divided into two.
We decided to use the same business logic in two versions of the project. There is one backend, but two completely different views.

When there is work with the front, there are no problems. We switched to the desired branch, created a feature-branch from it and further along the usual flow. But when it comes to backend development, you have to make a feature, release it, and then do the same again for the second version of the prod.
Not very comfortable. At the same time, everyone - the logic that is being written, it is 100% unique and there are no conflicts with any of the versions of the prod.

Visualization:


Is it possible to somehow release features in two versions of the product at once? That is, somehow solve the problem at the level of the version control system, and not at the level of the project architecture?

Answer 1

It does not happen that there are several prods with different features.
If you have, then you call things with the wrong words.
Understand in what order and by what principle features are uploaded to these branches.
If these are just two nodes, then you need to deploy not with a git for each individually, but with the help of a separate tool that is designed for this.
But if specifically on the question - there is no such feature in the git to merge one branch simultaneously into two others - this will have to be done in two separate operations (merge into the first, and then merge into the second).
UPD:
Looked at the illustration and saw the phrase "Production divided into two instances"
Git should not know how many service instances you have.
What will you do if at some point you have 100 instances that can dynamically scale up to 500 and back?

Answer 2

Option two.
1. Repartition the directories in the repository so that common things are / common, different things are in / prod1 / prod2 and, when building, respectively, collect different distributions from (common + prod1) or (common + prod), each with its own set of features. To do this, jobs in CI are different to do. You can even distribute developers to different teams. Depends on how far your products will spread
2. Make the inclusion of features dependent on configs. Then the distribution kit will be one, but in the prod1 config it will be feature1=enabled, feature2=disabled and in prod2 it will be the other way around.
Choose what suits you best. Maybe some mixture.