configuration option to use pull requests instead of just merging #266

Open
Chuckv opened this Issue Oct 4, 2012 · 1 comment

Comments

Projects
None yet
2 participants

Chuckv commented Oct 4, 2012

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment