Git flow with testing?

Question

git

Good afternoon.
I want to promote git as the main version control system in the company. Currently using TFS. I used to work with gitflow, but so far I can’t give myself an answer that git will pull the current implementation process.
So. Now there are 3 stages of product development.
Releases are permanent.
The first stage of virgins. The development is working.
Second stage testing. Testers and analysts work.
Third stage prod. Release.
The process is like this. From the maiden revision gets to testing. If the testing passes, then from the maiden revision it gets to the production.
OK. My guess is how this can be done within gitflow.
All created features are not pushed to dev on a remote repository, but to some kind of test. And if my revision is being tested in test, then I already push to dev, there, let’s say, they review it on some Gitlab and merge into master, which is the prod branch.
Further release branches and all.
In principle, not bad, but the future will not be closed, because there is a gitlab that pushes to the master. These are trifles. If you have any suggestions for improving the scheme, please write.
And another question. I'm not a ninja in Gita. Let's say, it happened that I pushed the improvements to the test and something critical bent down. 6 more people pushed after me. In Gita, is there any way to cut my commit, or at least rollback the entire branch to the desired state?

Answer 1

What you call "testing" is "acceptance".
You need to test in your branches and in develop. CI to the rescue.
Review should be done during merges in develop and not after acceptance.
With the review of git flow sucks lives. But no one bothers to work with branches "as in git flow".
Develop will need to tag with suffixes so that later the release will start with a tag. It's almost like in "git flow". And then let the acceptance play in its branch. Actually, according to the git flow, they will work in the release branch.
And this is if everything is with a monorepo.
It is not good to roll back develop, because if something is broken - well, figs with it - develop does not guarantee working capacity - they fixed it with a separate merge.
UPD: hehe memory did not fail - https://habrahabr.

Answer 2

I think the idea of ​​gitflow is not quite assimilated https://habrahabr.ru/post/106912/
features are made in separate branches, when ready they are assembled into a release (via PR), it is sent for testing, bug fixes arrive, as a result, everything rolls into battle and so in a cycle. The settled release is merged into the master. Plus, small deviations are possible due to the specifics of the development processes in the campaign, but the vector in most cases is the same