2

We are currently working on a non open-source project, with a team of around 50 people, with an average of 20-30 daily commits. As some of these people are junior developers, we had to implement a system that didn't allow all of them to commit to our main repository.

Until now we were using SVN with this structure:

  • trunk - Contained all the developers code
  • branch - Contained all the validated code

From time to time, one of the senior developers "goes into" the trunk and merges it with the branch, rejecting all the non approved code (this would become crazy when there would be a lot of non approved code to revert). Finally, when the trunk only has approved code, there's a complete merge between the both.

Recently we started making some tests with Git and GitLab, to see if the Git approval system was worth the migration from SVN, to soften up all this merging madness.

At first it looked promising, but after a while we came to a disappointing conclusion that there was no magic formula. We created a protected master branch where only the senior developers would have access to push changes to, but then came the problematic part... the junior developers.

Maybe because we are so accustomed to the SVN way, the only solution that we found was to create a "junior branch", but this would basically mimic the behavior (and headaches) we already have with SVN.

Please tell me there's something that we are missing, or if we are handling the problem in the wrong way.

EDIT When I say approved code, I'm referring to validation for all the classes structure, correct objects instantiation... and not if the line breaks, tabs (and similar) are correct.

Gonçalo Cardoso
  • 2,253
  • 4
  • 34
  • 63
  • the most important part that you're missing is that there won't be *one* "junior branch". Every developer will have their own copy of the complete repo and their own branches, so picking single commits into the "blessed" master is a lot easier (assuming your developers dont create a lot of inter-dependencies) – Nevik Rehnel Apr 15 '13 at 14:42
  • also, you're not the first people to face this kind of problem. There are numerous software solutions available under the keyword "code review", a number of them open source – Nevik Rehnel Apr 15 '13 at 14:47
  • @NevikRehnel So what you are telling me is that the junior developers shouldn't push the code into the "server" master branch, but instead the "server" should pull the changes? – Gonçalo Cardoso Apr 15 '13 at 15:55
  • What about implementing something like GitHub Fork / Pull Request? – Gonçalo Cardoso Apr 15 '13 at 15:56
  • Yes, the integrator(s) should pull code they want to put into the central repo. And yes, Github's PR system is one example for code review – Nevik Rehnel Apr 15 '13 at 16:20

1 Answers1

0

This kind of policy was easy to setup when GitLab was using Gitolite, because of VREF.

You could associate an update hook with a gitolite rule, which could be defined for a group of user (team in GitLab) called "juniors", and enforce any policy you want.

But since GitLab 5.x, gitolite is no longer used, and gitlab-shell manages permissions instead.
Hopefully, Issue 14 will be addressed.
In the meantime, you would need to implement and deploy an update hook yourself, in order to enforce a policy for junior developers pushing to a particular branch.

As commented, the other approach is to:

  • not add said junior developers to the project
  • fork (clone on the server) the project: that feature is being developed right now for GitLab V5 (issue 3382)
  • Make a pull request (called "merge request") for now.

Considering the current state of development for GitLab, that Git management software alone isn't ready yet to provide everything what you need.

Combining those repos (the main one, and the one for junior developers) with a review system like Gerrit might be a more sensible approach (here is an interesting criticism of that combination).

Community
  • 1
  • 1
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • This doesn't seem like much of an answer, it really just points out a feature that isn't working – Nevik Rehnel Apr 15 '13 at 16:19
  • @NevikRehnel Fair enough. I have expanded the answer. – VonC Apr 15 '13 at 17:24
  • @VonC Not including the junior developers is out of the question, so what you are saying is that currently I should create branches for them to work on and then have merge requests, right? – Gonçalo Cardoso Apr 17 '13 at 11:01
  • @balizeiro not just branches but a dedicated clone (a fork) for the junior developers to use, and for them to make merge requests. – VonC Apr 17 '13 at 11:07