-
Johannes Keyser authoredJohannes Keyser authored
layout: page
title: Help
permalink: /help/
ref: help
lang: en
Here you find some first aid on the use of JLU GitLab, but it cannot replace the official user help{:target="_blank"}. For specific information about JLU GitLab, see information.
Content {#toc}
- Important concepts
- How to use GitLab?
- First steps
- Visibility of projects
- User roles in projects
- User groups
- Settings concerning private information
- Last steps
- How to delete my account?
- Further help
Important concepts {#essential_terms}
Git and GitLab are versatile tools with many technical concepts and terms. Because their development and terminology is created in English, these terms have been only partially translated into other languages. To keep the following help entries (e.g. regarding read and write permissions) short and comprehensible, the essential terms are explained here in plain English. This is only a well-intended overview; further help provides a collection of links to familiarize yourself with these concepts.
Git terminology {#terms_git}
- Git{:target="_blank"} is the name of a software for version control of files.
- A repository is a collection of files where edits are versioned as a history of snapshots. With Git, you can manage multiple separate repositories.
- A commit is one snapshot of the data in the repository. Upon creation of a commit, the configured email address, name, date, time and an arbitrary comment become indivisibly connected with the file contents of the new snapshot. This is a fundamental security feature of Git to prevent future changes of this snapshot. Read here how to change these potentially private settings.
- A branch is a subset of snapshots with an arbitrary name, and helps to keep a repository neat and tidy.
- The Git commands pull and push can synchronize branches of Git repositories across devices (such as your own computer and JLU GitLab). Once two repositories are synchronized, they have both a copy of all data, i.e. the full history of snapshots.
GitLab terminology {#terms_gitlab}
- A project on (JLU) GitLab nearly always contains a Git-Repository, and offers many additional functions for its management. In addition, GitLab offers multiple systems to automatically execute source code within the project, e.g. to run tests or to generate a website (like this one).
- Every project is assigned to a namespace of a user or a group. All users have their own namespace for their personal projects. Likewise, all user groups have their own namespace for group projects. Your read and write permissions in a project depend indirectly on the namespace: For projects in the namespace of other users, your permissions depend on the project's visibility and if you are a project member, your role in the project. For group projects, the permissions depend further on the group's visibility and for group members on their role in the group.
How to use GitLab? {#how_to_gitlab}
TODO: Browser sufficient for many smaller things, for serious work you should install Git locally.
TODO: Note existence of Git GUIs (maybe including endorsement)?
TODO: Refer to Git functions within Matlab and other IDEs?
First steps {#first_steps}
TODO: Rough overview, links to good resources for learning more (see further help below).
TODO: Where to find language setting.
TODO: Link to guided Tour within GitLab (or is this just an EE feature?).
Visibility of projects {#project_visibility}
Every project has a visibility setting as either private, internal, or public. The visibility can only be changed by the Owner of the project (see user roles below).
- Projects with private visibility are only visible to the members of the project.
- Projects with internal visibility are visible to anyone with a user account who is logged in.
- Projects with public visibility are also visible for people without a user account.
Please read here what the visibility levels internal and public mean in the case of JLU GitLab. For more details, please refer to the official documentation{:target="_blank"}.
User roles in projects {#project_roles}
When adding project members you have to assign them a designated role: You can pick either Guest, Reporter, Developer, Maintainer or Owner. Each role is associated with an increasing set of permissions, see also the official documentation{:target="_blank"}. For projects in the namespace of a group, the group members will get the respective group role; e.g. a Guest in the group will also be a Guest in all group projects, unless it is overwritten by individual project roles.
Permissions as Guest {#project_guest}
The Guest role is for not-active members who can only read some content, and open issues and leave comments.
Project members with the Guest role can download the project, leave comments, view and pull project files, view wiki pages, create new issues, see related issues, create confidential issues, and view self-created confidential issues. If Public pipelines is enabled in Project Settings > CI/CD, they can also see a list of jobs, see a job log, and download and browse job artifacts.
Permissions as Reporter {#project_reporter}
The Reporter role is for members who get more insights and can work in the issue tracker. Project members with the Reporter role get the following permissions in addition to the Guest role:
Regarding issues, Reporters can assign and label issues, lock issue threads, and manage the issue tracker and labels. Reporters can also create code snippets, see a commit status, see a container registry, see environments, see a list of merge requests, view project statistics, and view the Error Tracking list.
Permissions as Developer {#project_developer}
The Developer role is for members who actively contribute, and have access to everything to go from an idea to its execution, unless something has been explicitly restricted (e.g. through branch protection). Project members with the Developer role get the following permissions in addition to the Reporter role:
In the repository, Developers can create new branches, and push to, or remove non-protected branches. Regarding merge requests, they can create new ones, manage/accept, assign and label existing ones, and lock merge request threads. They can create new environments and stop them. Further, Developers can cancel and retry jobs, create or update commit status. They can update a container registry, or remove a container registry image. In the issue tracker, they can create/edit/delete project milestones, and add tags. They can apply code change suggestions, create and edit wiki pages, and rewrite/remove Git tags.
Permissions as Maintainer {#project_maintainer}
The Maintainer role is for members who manage a project and its members. Project members with the Maintainer role get the following permissions in addition to the Developer role:
Maintainers can add new project members, use environment terminals, enable/disable branch protection, push to protected branches, turn on/off protected branch push for Developers, enable/disable tag protections. Maintainers can edit the project settings, add deploy keys to the project, and configure project hooks. They can manage Runners, manage job triggers, and manage environment variables. If GitLab Pages is activated, they can manage and delete them, and manage their domains and certificates, They can manage clusters, edit comments posted by any user, manage Error Tracking, and delete wiki pages.
Permissions as Owner {#project_owner}
Users with the Owner role control all aspects of a project, including its removal. In personal projects (within the namespace of a user), exclusively that user has the Owner role. In group projects (within the namespace of a group), multiple Owners may exist, if multiple group members are Owners as their group role. Project members with the Owner role get the following permissions in addition to the Maintainer role:
Owners can switch the visibility of the project, transfer the project to another namespace, remove the project, delete issues, and disable notification emails.
Note that according to the terms of service of JLU GitLab, Owners are held responsible for all content in their projects, even it came from other users.