How to do a branch per task strategy with git

The git flow model you mention is designed specifically to solve your problem :). Although it shows commits to develop, all tasks should be done in their own feature branch, and only merged back to develop once complete and tested. That way you know you can always release from develop (i.e. merge to master and tag), so it supports regular and continuous release.

Branch-per-task works really well with git flow because branching is cheap. We also use our issue numbers as prefixes, so git flow feature start PR-123_make-widget has a useable branch name but also highlights issue PR-123 in our JIRA.

Following the git-flow method as described above gives you a stable development branch (or maybe multiple stable development branches if you're working on a major new version branch as well as develop. You are also able to do hot-fixes which are applied directly to master and then merged back into develop.

For your 'request for merge', you could use pull requests (if you're using Github, Stash, Bitbucket, etc) or you could use a tool like Gerrit.

There's a reasonable argument that any branch which passes all tests should be merged back to develop automatically, in which case you could try doing per-commit micro reviews on feature branches. There are loads of options!

Update If you are going to persevere with your suggested model, I would recommend considering how your release cycle works. Does the release just involve tagging and pushing, or do you feature freeze for some time to carry out additional QA? Might you ever do that in the future? If the answer is 'yes' or 'maybe' then you shouldn't release from master, but should instead create a release branch, carry out your last minute fixes, and then tag and push. Don't forget to merge back as well though.

Update If you are employing a branch-per-task strategy it might appear that the master branch serves no real purpose. If you are doing continuous release, so every stable develop branch build is deployed to your production environment automatically, this is probably true. In an environment where a build is promoted to production, without a release phase, i.e. the promotion doesn't involve any additional commits the additional branch is possibly unnecessary. The real benefit of the develop/master branching strategy comes when you have a release phase where final release fixes (deployment issues, last minute bugs, etc.) and general housekeeping such as version number bumps are done in a transient release branch.

Using the release branch and then merging that to a master branch means you can continue to merge stable features back into develop even though your release isn't complete yet.

It's also quite nice to have single commit points on the master branch, with each commit representing a release, but that's a purely aesthetic justification so isn't really that valid :).