README.md

Team Collaboration in GitLab

Project Roles

GitLab has a predefined set of roles with different permissions. To summarize:

1. Project Owner: the person who created the project. Has all the rights on the project (repository and associated functionality)
2. Project Maintainer: about the same as the Project Owner, but cannot change or remove the global project settings.
3. Developer: has read access to all the project's content, and can use the repository and the issue related functionalities.
4. Reporter: has mostly read access to the repository, but can also submit merge requests or issues.
5. Guest: mainly read access to the repository and othe project pages, but can also submit issues.

When working on a small-sized project, apart from the owner, the other members will have the developer role. If there is a significant and tech-savvy user community, the can be assigned a reporter role. The project owner (and maintainers) have the permission to manage membership. It is up to them to assign roles to every newly accepted user.

The project member management page is accessed through the Members item of the Project Information entry on the left panel.

Branch Protection

GitLab allows the project owner to restrict who can push to a branch or delete a branch, using the branch protection features. By default, the master branch is protected. So only members of the Maintainers group can push or merge into this branch. For medium to large size projects, it may be useful to protect other branches as well. For small projects, it may be unnecessary to protect the master branch.

Branch protection settings can be accesed from the left panel, using the Settings menu and the Repository entry and then expanding the Protected Branches section.

Merge Requests

When working collaboratively on a project, it is recommended not to merge or push to branches on which other people are susceptible to work as well. Instead, when a set of commits has been tested, it is recommended to create a Merge Request (or MR). An MR leaves an explicit track in GitLab of a set of modifications, whereas simple commit/push/merge operations quickly become invisible in the project's history. Moreover, an MR can be assigned to another project member, giving him or her the opportunity to review your modifications. If needed, the reviewer can require additionnal comments or even suggest fixes or enhancements. This reviewing process adds a lot of value to the project's code or document base.

Note

It makes sense to assign an MR to oneself, at least to keep track of "batches" of content that have been modified together. It also gives an opportunity to add more comments.

An MR follows the same principle as an ordinary merge, and is defined by a source and a target branch. Managing MRs in GitLab is done with the Merge Requests entry of the left panel. Also, when committing changes using the GitLab IDE, the default settings is to create a new MR. So this is another way to create a new MR.

The following screenshot show the MR creating interface:

The assignee of an MR automatically receives an email notification when it is created with a direct link to a page allowing him or her to review the MR.

The following screenshot shows an example of MR review page:

Note the Changes link rightmost on the line starting with Overview. This link allows the reviewer to inspect every detail of the changes included in the MR. The following screenshot shows an example of such a detailed changed page: