Which Git branching model you should choose depends completely on the development process you want to use. The popular “git flow” you mentioned is concerned with products that have clear releases and largeish features that are developed independently. The development branch represents those features that should be part of the next release.
This opens two opportunities where QA can be performed: QA can either be done release-oriented or feature-oriented.
In a release-oriented QA process, a release branch is started and QA reviews that state. If QA finds problems, you can fix them on the release branch which is later merged back into the develop branch. This assumes that there won't be any huge problems that would result in a feature from being rejected completely, so you do need some testing long before.
A release-oriented QA process can work very well with semi-frequent but regular releases, e.g one release per month. The devs spend one month preparing the next release. Then QA has one month reviewing the release. During this time, any found issues are fixed. At the end of the month, the version can be released and QA gets the next version from the developers. This avoids idle time for both QA and developers, at the cost of lengthening the cycle time between inception of a feature and its release.
In a feature-oriented QA process, the feature gets reviewed when it is merged into the develop branch. So the state of the develop branch is always QA'd and release-ready. This spreads out risk over a longer time and makes it possible to reject an unready feature before it is included in a release, without also delaying unrelated features.
The drawback is that you can QA at most one feature at a time, or you might miss interference between different features. This could be a bottleneck of a process, and discourages small, easily reviewed features.
Some QA activities can also be performed before anything is merged. E.g. if a feature involves user interface changes, then focused UX tests can be performed in isolation for that feature long before it may be released. This requires that devs can ask for QA assistance when they think it's useful, without having to navigate any red tape. This also requires that QA is sufficiently flexible to accommodate these requests.
All of these strategies can and should be combined. The closer you get to a release the more important QA is, but earlier feedback is more cost-efficient because changes can be made more easily.
Note that automation and tooling can have huge benefits here. This speeds up and streamlines your process, which can have an exponential effect on productivity. This starts with simple build and deployment automation so that QA can easily run the software of any branch they would like to review. Test automation can free up QA to do more valuable high-level tasks, such as feature validation, smoke testing, manual exploratory testing, and developing new test scenarios. This isn't really specific to any process or branching scheme, but solid tooling can make it easier to involve QA earlier in the development process.
