20

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!

Community
  • 1
Mike
  • 483
  • 1
  • 3
  • 12
  • 1
    `"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. – toniedzwiedz Jun 20 '14 at 22:38
  • 5
    Thanks Tom, my idea is by enforcing a standard policy, I'm eliminating room for error – Mike Jun 23 '14 at 12:53
  • 2
    Consider this blog entry from gitlabhq https://about.gitlab.com/2014/09/29/gitlab-flow/ – spuder Oct 18 '14 at 03:52
  • 1
    Please watch this: [Google I/O 2009 - The Myth of the Genius Programmer](https://www.youtube.com/watch?v=0SARbwvhupQ) – borisdiakur Nov 06 '14 at 10:03
  • You could have them use their own forks.... – Wildcard Feb 05 '16 at 20:07
  • FYI this works without issues on modern versions of gitlab. Permission to merge to a branch via the UI is a distinct permission from the permission to push to a branch. – Étienne Feb 12 '20 at 15:42

1 Answers1

15

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.

Screenshot - Protecting a Branch

Mike
  • 483
  • 1
  • 3
  • 12
  • 2
    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? – Adam Oct 17 '14 at 16:34
  • 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. – Mike Oct 17 '14 at 18:36
  • Thanks. I'm going to try either Review Board, Phabricator or Gerrit. Do you have some experience with any of them? – Adam Oct 17 '14 at 19:58
  • No, sorry I haven't tried any of those services. Do post an answer if you are successful. – Mike Oct 17 '14 at 20:56
  • Sure, unless I forget. BTW, I've added Barkeep to my checklist :) – Adam Oct 18 '14 at 10:45
  • The enterprise edition should allow workflow. Unfortunately 40 USD for each user and year isn't cheap – Michel Samia Mar 29 '16 at 07:49