We would like to use Driessen's git branch model but we also have QA side. I think I understand how this git flow works but I'm still not sure about testing. For example, I have five new features, each of them is in my own branch and I want to give these features to testing. Now I'm confused about where to merge them? To do develop branch? If so, what happen when QA refuses only two and I have already merged all five features? I would like to keep separating features in my own branches but I would like to use a pull request to see the diffs and type comments but again then there is a problem in which branch to merge?

In another words, according diagram all new features (i.e. 5) should be merged into develop branch. From develop branch to the release branch and then from release branch to the master (I don't care about hotfixes right now - they are pretty clear). But where is a space for QA and option they will refuse some of feature? What then I need to change in the diagram? I apologize for English, I do what I can.

1 Answer 1


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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.