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!

Improve this question
6
  • 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, 2014 at 22:38
  • 5
    Thanks Tom, my idea is by enforcing a standard policy, I'm eliminating room for error
    – Mike
    Jun 23, 2014 at 12:53
  • 2
    Consider this blog entry from gitlabhq about.gitlab.com/2014/09/29/gitlab-flow
    – spuder
    Oct 18, 2014 at 3:52
  • 1
    Please watch this: Google I/O 2009 - The Myth of the Genius Programmer
    – borisdiakur
    Nov 6, 2014 at 10:03
  • You could have them use their own forks....
    – Wildcard
    Feb 5, 2016 at 20:07

1 Answer 1

Reset to default
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 [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

Improve this answer
6
  • 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, 2014 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, 2014 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, 2014 at 19:58
  • No, sorry I haven't tried any of those services. Do post an answer if you are successful.
    – Mike
    Oct 17, 2014 at 20:56
  • Sure, unless I forget. BTW, I've added Barkeep to my checklist :)
    – Adam
    Oct 18, 2014 at 10:45

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.