LogicApps: Feature git branching strategy and environments

I am working with Git Azure DevOps and Azure Logic Apps and I was wondering what are the best practices in terms of branching strategy and environments because we may face some troubles, let me explain.

Currently we have 3 environments: DEV, PREPROD & PROD.

We have one repository per Logic App and one "main" branch per repository which is then deployed on each environment. Each Logic App contains multiple workflows and we have multiple feature branches (one per new feature).

So let's imagine I need to develop a new feature, I will create a new branch (FeatureA) based on "main". When my developments are done, I will create a pull request in the main and then I will deploy my main branch in DEV environment. After validation I will deploy main in PREPROD and again after validation I will deploy main in PROD:

But sometimes, this can lead to some troubles in the following case: If a FeatureB branch is pushed in the main between 2 deployments in different environments:

Here it means we will deploy in PREPROD and PROD both FeatureA and FeatureB but we may want to deploy only one of the two features.

How can we manage that through a different git branching strategy?

To sum up what I suggested in comments, here's a way to handle the situation (which is quite similar to a project I worked on):

Rather than using a main branch where every feature starts from and is merged into, create a branch for each environment (dev, preprod, prod).

It would entail the following workflow:

A feature branch is created off main, a developer works on it, then when ready the developer creates a PR into dev. At this point, review happens if your workflow requires it, then it's deployed to dev environment (depending on the specifics of your CI/CD chain).

Same principle for preprod environment. When the feature has successfully been tested in the dev environment, the developer (or alternatively, your release manager / devops) creates a new PR from the feature branch to preprod. Review, merge, deploy, and test (sometimes other people handle it in preprod, internal QA or customer QA, it depends on the project).

The day of the live deploy ("MEP" in french ;-) ) onto the prod environment, same thing when it comes to merging the features, but you'll have to merge prod into main afterwards, so that new feature branches can start from the state in production. In our case we also used to merge prod back into dev and preprod in case some features have skipped an environment, or some conflict has been handled slightly differently between envs.

As you rightfully mentioned earlier, there's an important catch. Merging dev / preprod / prod into feature branches (to solve conflicts) is now forbidden, because it would then "embark" everything from the environment into the feature, which would become "polluted" with unwanted things. You'll have to create a temporary resolution branch (from the destination, where you merge your feature) to avoid this and keep your feature branch clean.

Also, not sure you'll need both prod and main, as main will essentially represent the state of prod at some point. Could very well be handled through tagging prod after each live deploy, to mark where feature branches should be created from.

Another caveat: with time passing, your dev/preprod branches will (more or less) slowly diverge from prod/main, mostly because of features merged and tested but rejected for some reason, which never went all the way to preprod/prod. It can be solved periodically by resetting dev/preprod on main/prod just after live deploy.