Controlling the repos?

[steveschow]

Just getting into GIT and bitbucket, so please excuse my ignorance at this point.  I'm looking for wisdom about how to setup a repository, such that I can allow other people to create branches and work on new features, but nothing ever can be merged back into the main tree without my code review and approval.  From reading around it seems like that runs counter to the open source git revolution, but nonetheless that is what I want to be able to do, to have myself or perhaps someone else I choose to be gatekeeper and approve or deny any and all attempts to update the main branch (with a push is it?).  Conversely, I don't want to code review every single commit happening in their feature branch.  Its more like after they have a feature ready to merge back into the main trunk, I guess they submit a pull request right?  But then I want to code review the entire change that is being suggested, in comparison to what is currently in the main trunk, and only when I approve it, can it actually be pushed back into the main trunk.

Seems like GIT has a lot of flexibility to work in a lot of different ways, some more open then others, but its not entirely clear to me what is the best way to setup a process of how to go about handling that kind of release oversight and control.  

Any thoughts on this topic are welcome.  Thanks.

[steveschow]

right I read the paper about different branch models, and it seemed like the Fork model might be the only way to truly prevent unauthorized merging back to the main trunk.  Do I have that right?  I also read the white paper from the git-flow guy, and that is a very similar branching model we used to use under clearcase in my previous life at a software company.  Everything was tied into the issue tracking system, so someone could submit for approval a feature or bugfix, which would contain the changeset of file changes/additions applying to a particular issue#, then a code reviewer could check it out and approve it before it could be merged back to the development branch where nightly builds were occurring.

I get that GIT and bitbucket can branch and merge all over the place and that's great because we can use a sophisticated feature and release branching model to stage various things like that, but its just not clear to me where the checks are to make sure only authorized people can approve the merges back to development branch with code review of that intended merge, and especially merging the development branch back to main trunk should only be performed by authorized person.  Where does that security take place?  Do any of you reccomend certain kinds of wrapper scripts for some of those operations to ensure correct process?

[Seth]

You could require those "other people" to fork your repository, then submit pull requests as necessary.

[John Garcia]

This looks like a job for Branch Management. Simply put restrictions on Master, and perhaps Staging or one other stable-but-not-deployed branch.