Here’s documentation about using GitLab:

http://doc.gitlab.com/ce/

Here’s a good screencast about using GitLab:

https://about.gitlab.com/2014/02/26/getting-started-with-gitlab/
 

User and project creation policy and rationale for the gitlab service

 
Objectives

1. Admin privileges to gitlab should be given only to persons that administrate the actual gitlab service as such, and not be required by staff for their normal use of the gitlab service.
2. Management of individual projects should not require admin intervention. This includes e.g. creation and management of accounts and projects for students course or thesis work.
3. For each project there should be a the responsible person, typically a member of staff (e.g., for determining if/when an old inactive project can be deleted or for handling any suspicious or otherwise problematic activity).
4. Creation of users should be open to the world, but require some manual steps and email verification, to keep out spambots, etc.
5. Logging in with a Google account should be supported to reduce the number of passwords a user must remember

 
Policy / workflow

• Users must create an account on this gitlab instance, simply signing in using a Google account is not allowed. The default settings is that new users cannot create projects (i.e., project limit=0) and cannot create groups.
  This addresses objective 4, as creating an account involves entering name and email address, and then following a confirmation link in an email sent to the entered email address.
• The steps (performed by the user) to create a new account, and enable logging in with a Google account, are:
  1. Sign up with the web form at git.cs.lth.se
  2. Follow the link in the confirmation email
  3. Go to profile → edit profile settings → Account and click on the google link under “Social Accounts” to enable logging in with a google account.
• All members of staff, and otherwise trusted users, gets permission to create projects and groups. This requires a gitlab admin to change the permissions for the trusted users. (If desirable, the staff accounts can be created by a script, and then either distributing passwords, or let each user use the “forgot your passord” link to choose a password.)
• If more granularity, or access restrictions, instead of giving members of staff general rights to create projects and groups, one can create a set of groups (e.g., student projects, research groups or projects, etc.) and give each member of staff suitable permissions for each group. This has the drawbacks of requiring more work by gitlab admins and also removing the possibility to structure projects by creating groups (as gitlab doesn't support nested groups).
• Thus, imposing those limitations, is probably not a good idea for staff, but it may be useful for, e.g., a master's thesis project that will develop multiple unrelated or loosely coupled applications/libraries to create a group for that student project and give the student rights to create projects under that group. In this case, the responsible person(s) is the owner(s) of the group. (Note that the student must be given master privileges for the group to be allowed to create projects).
• The workflow for creating a project for e.g. a master thesis student is then
  1. The student creates a user account by signing up, and confirming the account
  2. The responsible teacher / supervisor creates a project (or group) for the student project
  3. The responsible teacher adds the student to the project/group with (typically) developer rights.
This addresses objectives 2,3 and 4. Responsible person(s) is identified as the creator, and any other owners or masters, of the project/group.