How to organize the GIT branching model and casting for staging?

Question

git

Hello everyone, I read the article: A successful branching model for Git / Habr I
liked the model, but there are still many questions that I want to get answers to.

Questions:

Introductory: Let's imagine that we have 2 branches: master - where release versions are cast and develop - where test builds are cast for QA testing before getting into the master. Auto-deploy is launched from the developer, after which the changes go to staging.

1. Let's imagine that after feature #1 was cast in development, it passed QA and we released a new release to the master. In order not to waste time, the team started implementing the next feature #2, and has already started making commits to the development, and now the development is in an unstable state, because what is there cannot be released. Suddenly, a bug is discovered in the release version No. 1, to fix it, the team starts a hotfix branch and merges the fixes into master and development. I don't like this approach, I want the new commit to be checked by QA after fixing the bug, but how to organize the staging space in this case? We cannot merge the code into unstable development and roll out to staging, since changes in the development may have an unstable effect on release #1. How to be?
   
2. Any code must be checked by a code reviewer when casting to the developer. Imagine that the developer has finished implementing feature #1, sent it to MP and wants to start feature #2, but to implement feature #2, he needs the code of feature #1, which has not yet been checked by a code reviewer and QA specialist, from where the developer should unpack into In this case, from a developer or from a branch with feature number 1?
   
3. Imagine that there are 2 features in the project, the first has the highest priority, the second has a slightly lower priority, it is natural that the team working on feature No. 1 makes commits and sends its code to the developer for merging. According to agile, the second team working on feature #2 cannot submit their code to development, otherwise it will slow down the delivery of a new release from feature #1. How to organize the work of the second team in terms of git and staging environment for QA testing? Create a test branch, where less priority code will be cast? And if there are 5 such features and teams, then it will be necessary to create 5 test branches and staging? How to be?
   

Thanks in advance for your replies!

Answer 1

one)

I want the new commit to be checked by QA after fixing the bug, but how to organize the staging space in this case? We cannot merge the code into unstable development and roll out to staging, since changes in the development may have an unstable effect on release #1. How to be?

What's the problem? Give hotfix to QA let them check it. As in the case of feature QA tests the release-... branch, so in the case of hotfix, QA tests the hotfix/... branch.
2)

where should the developer get dirty in this case, from the developer or from the branch with feature number 1?

If feature #1 depends on feature #2, and feature #1 is missing in dev, then it’s obvious that feature #1 is from the branch, I don’t see any other options.
3)

According to agile, the second team working on feature #2 cannot submit their code to development, otherwise it will slow down the delivery of the new release

Probably agile has nothing to do with it. If you work on scrum, then each sprint is the preparation of a new release and you cannot work on a feature not from this release. git-flow is geared towards this kind of work.
If the releases are floating, as I understand it, then do not merge features not from the current release into the branch from which you are preparing the release. If you do not go beyond git-flow, then do not merge branches not from the current release into dev, let QA test either feature or tags, if you work with pull-request, then approve them, but do not merge.
Of all the above, it seems to me that you have 1 only difficulty, this is the question of how QA should work.