when you see other presentations (such as the how git uses git one) a central theme seems to be the use of pull requests for code review etc as the process for accepting code from a branch back into master (or develop)
Is there a way to configure gitflow to work this way by default? otherwise I like the structure for projects that have to maintain releases on conjunction with development, but I hate the unreviewed no approval needed merging of features back into develop etc.
It seems strange to me that a 'professional' project which needs this kind of branching structure would not want to make use of pull requests to do code reviews and control the contributions of feature code back into critical streams like develop, release, master.. (especially for things like hotfixes back into master) If that's how things already work, then it was in no way clear from docs and demos
Isn't this an administrative issue? It's a matter how you set up your distributed workflow, not so much how you use git.
I mean anybody can clone the anything on github, make changes and push them back into their own master branch, develop branch, but only the administrator of the original repository can push changes into the official branch.
More information about this subject can be found at Distributed Git - Distributed Workflows