How to deal with multiple release/hotfix branches in Gitflow?

Question

I'm implementing Gitflow at the company I currently work for and everything is going pretty well. I'm just not completely sure if I'm dealing with more than one release on the pipeline at the same time in the best way

Our systems have 5 environments as follows:

• Develop: deployed whenever there is a merge into develop. Used for integrating other systems at dev-time
• Internal Test: deployed whenever a new release branch is created from develop. Used by QA team
• External Test: deployed after QA team gives their ok. Used for key users of the system to have a look and aprove what was done.
• Production: deployed whenever something is merged into master
• Mirror: deployed whenever something is merged into master. This one is a carbon copy of production for helping us debug production bugs in a safe way. Basically a sandbox with same code as production and the production database of the day before (except for some sensitive data being scrambled)

The problem I want to solve: While release 1.0.0 is being tested by external testing, I may already deliver a new release 1.1.0 into internal testing. But if the external testing finds something that needs to be changed in 1.0.0, this should be applied recursively back until develop, where we are already working on 1.2.0.

What we do today is merge 1.0.0 into 1.1.0 and develop after those changes and send it back to internal test, pausing tests on 1.1.0 in the meantime.

Same idea for hotfixes. I may have 1.0.0 in production and have 1.1.0 being tested. But suddenly I have to fix a prod bug, so I create a hotfix branch from master that will generate release 1.0.1. Today we merge that into 1.1.0, develop and master.

Does any of this make sense?

Is there any better way of dealing with this?

Thanks

Edit:

The original article about Gitflow already has a solution for the Hotfix problem:

[...] when a release branch currently exists, the hotfix changes need to be merged into that release branch, instead of develop. Back-merging the bugfix into the release branch will eventually result in the bugfix being merged into develop too, when the release branch is finished. (If work in develop immediately requires this bugfix and cannot wait for the release branch to be finished, you may safely merge the bugfix into develop now already as well.)

Answer 1

The process you described makes sense, especially if it is fairly rare that you have multiple active release and/or hotfix branches at the same time.

To keep the merging controlled, you could make the agreement that bugfixes on a release (or hotfix) branch are only merged to other release branches after QA gives their ok for external test on that branch.

According to Gitlow, the merge to develop should happen at the same time as the merge to master, unless there are pressing reasons that the fix is needed sooner on develop. You can choose to do the merge to develop also at the time that the release branch is made available for external testing.

Answer 2

It sounds like you work on a web application, or something similar in the sense that only one version is typically used at a time - whatever was last deployed to production. Given that, I'd suggest that Git Flow is probably not a good fit. As Vincent Driessen, who originally described Git Flow writes:

... Web apps are typically continuously delivered, not rolled back, and you don't have to support multiple versions of the software running in the wild.

This is not the class of software that I had in mind when I wrote the blog post 10 years ago. If your team is doing continuous delivery of software, I would suggest to adopt a much simpler workflow (like GitHub flow) instead of trying to shoehorn git-flow into your team.

My suggestion would be to look instead for some form of trunk based development.