Git merge strategies for Kanban, production support, environment

Question

We are currently re-evaluating our git merge strategy. Our current workflow for our existing "production support" projects is thus:

1. When you start development, you create your branch from the project develop branch.
2. When the work is finished, the code goes through a pull request back into the develop branch. This develop is a CICD branch, so that once a pull request goes through, all of those changes are testable in our development environment.
3. Once the work has been tested and the business team is ready for it to go to production, it is then cherry-picked into a branch that then gets merged into the master branch.

This seems to work for a while. However, sometimes a feature becomes lower priority, especially if a feature is buggy and the original developer has been already assigned to a higher priority task, we end up with a situation where our master branch is 100+ behind AND 100+ ahead. This means that the longer we go the less and less master looks like develop, and worse, and as time goes on it seems that the merges tend to cause more and more frequent and complex merge conflicts. The pain here has become acute enough to where we need a better solution.

I've looked at various strategies, especially the Feature Branch strategy, but I am concerned about some of the pieces of this, for example, how can we have a CICD branch with such a strategy... does each developer need a new development environment for each feature? What about features that build on top of other features, is there a good way to track such dependencies? Is there any other, better, way to manage our code churn without the pain? Don't know that it matters, but we use ASP.NET/C#.

Answer 1

What works for me/my job:

1. When you start development, you create your feature-branch from master-branch
2. When the work is finished, merge master branch into feature-branch (so it's 0 commits behind master, and some commits ahead)
3. run all testsuites
4. create pull request to master branch
5. code review and approve (if this step takes uncomfortably long, repeat step 2+3 before going to 6.)
6. merge into master
7. release from master branch

how can we have a CICD branch with such a strategy...

Docker containers replicating production systems. At my job, we make extensive use of Docker containers to locally replicate production systems. (Right now we have 8 Docker containers running in parallel on dev laptops to simulate 8 different production systems)

does each developer need a new development environment for each feature?

it's the same environment regardless of branch (with the exception of upgrading OS versions/docker configurations, eg ubuntu 20.04=>22.04 branch - in theory this means that we need to re-build the docker containers each time we switch from/to such a branch, but in practice the developer working on that branch just stays on that branch until it's merged into master. It's not often the docker configurations change anyway, maybe 4 times a year on average)

What about features that build on top of other features, is there a good way to track such dependencies?

build on top of un-released features, you mean? lets say you have master, feature-branch1 and want to create feature-branch2 which depends on feature-branch1, fork feature-branch2 from feature-branch1 instead of master, then if feature-branch2 is finished before feature-branch1, make the pull-request to the feature-branch1 branch instead of master (but if feature-branch1 is merged to master before feature-branch2 is ready, then make the pull request to master) - in practice this rarely happens anyway (in my experience)