Git is a distributed version control system for software source code and other files. Using version management makes it possible to track changes made to files. It facilitates collaboration between multiple people on a project because concurrent changes cannot lead to accidental overwriting of files, hence preventing information loss. Changes made by multiple people can be merged using the Git software. Versioning of files is often used in software development, but it is also suitable for working on scientific texts such as graduation and doctoral theses that are often written using the LaTeX document preparation software.

With GitLab, the LRZ offers a web-based service for managing Git repositories. In addition to the actual repositories where the files are stored, GitLab provides tools such as wikis and an issue tracker. With "Merge Requests", code reviews can be carried out collaboratively and transparently.

Below you will find an overview of the LRZ GitLab installation. Further information can be found in the GitLab-FAQ.

Terms of service

All members of TUM, LMU and other Munich universities are entitled to use the LRZ GitLab service. This requires an LRZ, TUM or LMU user ID.

If no automatic activation has been made, individual user IDs can be activated by the responsible master user via our ID Portal. If this is not possible, please contact the LRZ Servicedesk.

Storage space

Since Git is designed for versioning of text files (source code and other files in text format), Git repositories should remain relatively small (in the two-digit MB range).

For binary formats such as image archives, Microsoft Office files (.doc, .docx, .xls, .xlsx etc.), LibreOffice / OpenOffice files (.odt, .ods etc.) or very dynamic data, GitLab supports the extension Large File Storage (LFS). The maximum upload file size is 2 GB and the total limit for data in the LFS is currently 25 GB.

As it sometimes cannot be avoided that individual projects get larger, there is currently no fixed storage limit. Should one of your projects become disproportionately large, you will be contacted by the LRZ team to work out a solution. To maintain safe and stable operation, we reserve the right to temporarily block write access or to disable very large projects.

Project limit

10 personal projects may be created at most. This limit can be raised in justified cases. Please contact the LRZ Servicedesk.

Groups

For logically related projects, the use of GitLab groups is recommended. Within a GitLab group, the number of projects is not limited. A group also has the advantage that rights management usually becomes easier and clearer. In addition, the role of a user of a group is inherited to all projects in the group.

Public projects

It is possible to publish projects so that they can be cloned without logging in. The required setting for the project can only be made by the GitLab administrators. Please pass on the project name or path with a corresponding message to the LRZ Servicedesk and use the button "Selfservice" to make an authenticated request.

We recommend grouping all public projects into groups so that they are not dependent on personal GitLab identifiers. If a project is to be publicly visible, the group which the project belongs to must also be made public.

For public projects, the following information is publicly visible (generally accessible):

• On every commit: The name and email address stored in the Git configuration
  
• The GitLab username as defined in the User Settings in the Account section. For personal projects, the username is visible in the path of the project.

When you log in to GitLab for the first time, the GitLab username is initialized with your own user ID, which is assigned by your own institution (LMU, TUM, HM, HSWT). We ask all members of public projects to change their GitLab username (Settings → Account → Change Username), so that their own user ID will not become generally visible. Reasons in detail:

• For privacy reasons, the LRZ must treat the user ID as confidential information.
• The user ID can be used in a social engineering attack in order to build confidence in the victim: << Dear customer with the identifier Abcxyz >>
• There are several variants of password attacks. In the "Online Attack" scenario the attacker attempts to gain access using the normal log procedure. However, the attacker must know or guess both the user ID and the associated password.

When the GitLab username is changed, GitLab automatically adjusts the web addresses and repository URLs of the user's personal projects accordingly. For projects that belong to a group, nothing changes because there is no username in those URLs. Further details on changing your own GitLab username can be found in the GitLab documentation.

GitLab Pages

The GitLab Pages feature makes it possible to create and publish static web pages directly from a repository. All LRZ GitLab Pages are served as subdomains under pages.gitlab.lrz.de. All LRZ GitLab Pages can be reached using a secure connection (HTTPS).

By default, a new GitLab Page is accessible only to project members who are logged in. However, the Page can also be made generally accessible (Settings → General → Pages access control → Everyone).

A CI runner is required for the Pages functionality.

The CI/CD integration can be activated at the project level (Settings → General → Permissions → Pipelines). However, you can only configure the communication with a CI runner. LRZ does not provide shared CI runners until further notice, which means you will have to set up and operate a CI runner yourself.

See the following GitLab documentation for more details:

• Overview documents of CI Runners and CI/CD
• Installing a CI Runner
• Registering a CI Runner
  

The GitLab Pages documentation presents the Pages functionality in detail. There you will find for example a detailed description about how the address of your GitLab Page is formed. (The documentation uses example.io as an example domain which corresponds to pages.gitlab.lrz.de on the LRZ GitLab platform.)