Simplifying git flow workflow

Question

While trying to simplify :

while having the requirements:

1. Running Parallel masters
2. Running Feature branches, that might / might not be released
3. Handling Hot Fixes
4. Handling Vulnerability Fixes

Looking at A successful Git branching model

Can we do away with release branch as long as we tag the master branch after every release?

Can we also do away with develop branch?

Release branch can be branched off master at the start of the new sprint and devs can create their features branches off of that. If a hotfix merge to master (current release) happens in the middle of a sprint, the hotfix can also be merged to the current release branch at the same time as feature-branch-hotfix-

Code from feature/develop branches should be deployed to DEV environment

Feature branches by themselves should not be deployed at all.

Prefer my strategy in which a merge request from release-* to master kicks off the jenkins pipeline build via webhook, that will auto merge release-* to master, build from master and tag the merge commit.

Answer 1

If you want a simpler (and more flexible) workflow, consider the gitworkflow.

You don't merge dev to master: you only merge feature branches.

Merge feature branches to:

• dev for integration testing
• master to preparing the next release
• another release branch if you maintain/prepare multiple releases in parallel

I detail that model further here and illustrate it here

One important point: the dev branch (for integrating feature branches together) is transient: it is created/destroyed for each new release (as opposed to one fixed eternal dev branch merged to master from time to time).

You recreate as many integration branches you need to testing features together.
Then, when ready, you only merge the right feature branches to master (or any other release branch), delete your dev branch, and recreate it for the next release.