[davnicwil]

Within gitflow it is definitely necessary to have an integration branch - it doesn't really matter if you call it develop, or you progressively merge different features branches down together, or group them into one feature and just develop them all on one feature branch from the get go, the result is the same - you end up with all your code integrated on one, not necessarily always stable, branch.

The idea in gitflow is that you then isolate a snapshot of that integration branch, whatever form or name it takes, as a release branch, and only when that release branch produces a build passing all tests is it then merged to master (and probably tagged).

You mention you auto-deploy from HEAD of master after tests pass - does that mean that code at the HEAD of master may not pass tests, or that you merge code to master only if it has passed tests. If it's the former, then you're not using gitflow, and I was just explaining the use of separate master and develop in gitflow, not implying that this is the one true branching/release strategy. Using something other than gitflow can work equally well. If the latter, then you are using an integration branch - the one you run the tests on before merging to master.

As to the point about release frequency, having a set of features to release in batch was just an example - if you're in any situation where other developers may commit things to the branch that will ultimately be released from between the time you create your feature branch and the time you merge it, then gitflow is useful - be that on a scale of minutes, hours, days or weeks.