Gitlab workflow, forcing code review or merge request on branch

Question

I'm working towards implementing Gitlab at my company with a workflow strategy. My idea is that developers will be given access to repositories but, anytime they try to commit, their code must be reviewed.

I know I can have them create a branch before committing, and then create a Merge Request after it's been pushed to the repo. I'm still unclear about certain things... The idea that we rely on people to create a branch and then a merge request seems faulty, is there a solution that forces some sort of policy that the master branch can stay clean unless an "admin" approves the code that's about to merge into it. I've read "github team workflow" but it doesn't seem to offer a viable solution. Any advice about process or your own best practice is appreciated. Thanks!

• toniedzwiedz: "The idea that we rely on people to create a branch and then a merge request seems faulty" It seems to me that you have a bigger problem than a lack of features in a version control system. If it's only a matter of spending the extra time creating a branch, take a look at Atlassian Stash and its integration with Jira.
• Mike: Thanks Tom, my idea is by enforcing a standard policy, I'm eliminating room for error
• spuder: Consider this blog entry from gitlabhq about.gitlab.com/2014/09/29/gitlab-flow
• borisdiakur: Please watch this: Google I/O 2009 - The Myth of the Genius Programmer
• Wildcard: You could have them use their own forks....

Answer 1

I've started working with gitlab, reading the HELP section provides a workflow layout. At this point, this seems to be the best solution to my question. If anyone has experience with this workflow or advice, please add any additional info.

From the HELP section:

Workflow

1. Clone project
   git clone [email protected]:project-name.git
2. Create branch with your feature
   git checkout -b $feature_name
3. Write code. Commit changes
   git commit -am "My feature is ready"
4. Push your branch to GitLab
   git push origin $feature_name
5. Review your code on commits page
6. Create a merge request
7. Your team lead will review the code & merge it to the main branch

In the commits section of your repository, you're actually able to protect branches which forces developers to follow the process above, creating a branch and submitting a merge request.

Screenshot - Protecting a Branch

• Adam: Is there any way to enforce this workflow (eg. using protected branch) but allow any assignee (not only team lead with Master/Admin privileges) to merge the request?
• Mike: I just tried to assign a merge request to someone without master privileges and they get the following message in the merge request, This can't be merged automatically, even if it could be merged you don't have the permission to do so. So, doesn't appear they'd be able to.
• Adam: Thanks. I'm going to try either Review Board, Phabricator or Gerrit. Do you have some experience with any of them?
• Mike: No, sorry I haven't tried any of those services. Do post an answer if you are successful.
• Adam: Sure, unless I forget. BTW, I've added Barkeep to my checklist :)