-
Johannes Keyser authoredJohannes Keyser authored
Help
This page offers you some introductory information on how to use JLU GitLab, but it cannot replace the official user help. For specific information about JLU GitLab, see information.
- Help
Important concepts
Git and GitLab are versatile tools using many technical concepts and terms. As both are developed and created in English-speaking environments, these concepts and terms have been only partially translated into other languages. To keep the following list of helpful information (e.g. regarding read and write permissions) short and comprehensible, the essential terms are explained in plain English. This is only a well-intended overview; further help provides a collection of links for you to familiarize yourself with these concepts.
Git terminology
- Git is a software for version-controlling files.
- A repository is a collection of files, which depicts edits of those files as a history of snapshots. Using Git, you can manage as many separate repositories as you want.
- A commit is a snapshot of the data in the repository. When you create a commit, the configured email address, name, date, time and a random comment become inseparably 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 that has been given an arbitrary name, and which helps to keep a repository neat and tidy.
- The Git commands
pullandpushcan synchronize branches of Git repositories across devices (such as your own computer and JLU GitLab). As soon as two branches are synchronized, both of them contain a copy of all data, i.e. the full history of snapshots.
GitLab terminology
- 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 the namespace of an individual user or a group of users. 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 for a project depend indirectly on its namespace: For projects within 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?
- TODO: Using the browser is sufficient for many small issues, but for more serious work you should install Git locally.
- TODO: Many of the most common scientific softwares such as MATLAB, RStudio, etc. have integration with Git.
Please note that access from the Internet is restricted to HTTPS; access via SSH is only possible via VPN.
How to register an account?
To create an account for JLU GitLab, an existing JLU account (g-, s-, n-, or j-) is required. Please refer to this page for information on JLU accounts.
If you have a JLU account, your account for JLU GitLab will be registered upon your first login, if you agree to the Terms of Use. To login, go to https://gitlab.ub.uni-giessen.de/ and enter your JLU user ID (g-, s-, n-, or j- account) into the field JLU (g-/s-/n-/j-) Username and your corresponding, personal password into the field Password.
Upon your first login, you will be prompted with the Terms of Use (in German); your account be registered only after you agree to it.
First steps
TODO: Rough overview, links to good resources for learning more (see further help below).
- You can choose another language at Einstellungen > Profil > Einstellungen > Lokalisierung. But as GitLab uses many untranslatable terms, there might still be many English terms, despite different language settings.
TODO: Link to guided Tour within GitLab (or is this just an EE feature?).
Visibility of projects
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. For group projects, this includes the group members, depending on their role.
- Projects with internal visibility are visible to anyone with a user account who is logged in. Please read here which people are included.
- Projects with public visibility are visible for people without a user account who can access JLU GitLab. Please read here which people are included.
For more details, please refer to the official documentation.
User roles in projects
When adding project members you have to assign them to a designated role: You can pick either Guest, Reporter, Developer, Maintainer or Owner. Each role entails an increasing set of permissions, see also the official documentation. For projects within 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 that is overwritten by individual project roles.
Permissions as Guest
The Guest role is for non-active members who can only read some content, and open and comment on tickets.
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
The Reporter role is for those members who get more insights and who work with the issue tracker. In addition to those of the Guest role, project members assigned to the Reporter role have the following permissions:
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 the container registry, see environments, see a list of merge requests, view project statistics, and view the Error Tracking list.
Permissions as Developer
The Developer role is for members who actively contribute, and have access to everything throughout the entire project process, unless something has been explicitly restricted (e.g. by branch protection). In addition to those of a Reporter role, project members assigned to the Developer role have the following permissions:
In the Git-repository, Developers can create new branches,
and push to, or remove non-read-only branches.
They can create new merge requests,
manage/accept,
assign and label existing ones,
and lock merge request threads.
They can create new environments and stop them.
Additionally, Developers can cancel and retry jobs,
and create or update a commit status.
They can update a container registry, or
delete an image from the container registry.
They can create/edit/delete project milestones and add tags in the issue tracker.
They can apply code change suggestions,
create and edit wiki pages, and
rewrite/remove Git tags.
Permissions as Maintainer
The Maintainer role is for members who manage a project and its members. In addition to those of the Developer role, project members assigned to the Maintainer role have the following permissions:
Maintainers can add new project members,
use environment terminals,
enable/disable branch write protection,
push to protected branches,
turn on/off write-protected branch push for Developers,
enable/disable tag write 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.