Merge branch 'team-collaboration' into 'main'

Include collaboration section into main branch.

See merge request !10

05-team-collaboration/README.md

+# Team Collaboration in GitLab
+
+## Project Roles
+
+GitLab has a predefined set of [roles with different permissions](https://docs.gitlab.com/ee/user/permissions.html). 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.
+  4. 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.
+
+![gitlab-members.png](./media/gitlab-members.png)
+
+## Branch Protection
+
+GitLab allows the project owner to restrict who can push to a branch or delete a branch, using the [branch protection](https://docs.gitlab.com/ee/user/project/protected_branches.html) 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.
+
+![gitlab-branch-protection.png](./media/gitlab-branch-protection.png)
+
+## 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:
+![gitlab-create-mr](./media/gitlab-create-mr.png)
+
+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:
+![gitlab-review-mr.png](./media/gitlab-review-mr.png)
+
+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:
+![gitlab-mr-details.png](./media/gitlab-mr-details.png)
+
+
+
+
+
+

05-team-collaboration/exercises.md

+# Team Collaboration in GitLab - Exercises
+
+## Membership Management
+
+Use the GitLab membership management tool to add some of your classmates' accounts to your project.
+
+## Branch Protection
+
+Use the GitLab repository settings page to unprotect the `master` branch.
+
+## Merge Requests
+
+Use the GitLab Web IDE and the project of one of your classmates:
+  1. Create a new branch.
+  1. Add some contents to the branch.
+  1. Commit the changes using an MR.
+  1. Assign the Merge Request to the project owner.
+
+When one of your classmates has submitted an MR to your project:
+  1. Review the changes.
+  1. Make some comments.
+  1. Accept the MR.
+
+
+
+
+
+
+
+
+
+ 
+
+

README.md

@@ -36,13 +36,13 @@ Training material for the Git for Beginners ABiMS training session
   1. Using GitLab to manage branches
   1. Using the CLI to manage branches
 
-### Team collaboration
-  1. Project roles in GitLab
+### [Team Collaboration in GitLab](./05-team-collaboration/README.md)
+  1. Project Roles
   1. Branch Protection
   1. Submitting Merge Requests
   1. Handling Merge Requests
 
-### Using Git through third party tools
+### Using Git With Third Party Tools
   1. Using Git inside R-Studio
   1. Using Git inside PyCharm