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!

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 git@example.com: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.