Ein persönliches Zugriffstoken (Personal Access Token) ist eine zufällig generierte Zeichenkette mit bestimmten Berechtigungen, die anstelle eines normalen Passworts verwendet wird. Es können mehrere Token mit unterschiedlichen Anwendungszwecken und Berechtigungen erzeugt werden.

Neben persönlichen Zugriffstoken gibt es auch solche für Projekte und Gruppen. Diese werden analog zu einem persönlichen Token benutzt, aber erlauben eine zusätzliche Berechtigungsbeschränkung auf einzelne Projekte oder Gruppen.

Persönliche Zugriffstoken werden in der Weboberfläche von GitLab verwaltet. Man erreicht diese, in dem man oben links auf sein Profil klickt und anschließend Einstellungen > Zugriffstoken wählt.

[Bild]

Man erstellt ein neues Zugriffstoken über die Schaltfläche "Neuen Token hinzufügen":

• Der Token-Name ist beliebig und dient später nur der eigenen Übersicht.
• Das Ablaufdatum gibt an, wie lange das Token gültig sein soll. Die Voreinstellung ist 1 Monat. Die maximal zulässige Dauer ist 1 Jahr.
• Dem Token können verschiedene Geltungsbereiche zugewiesen werden, je nach dem jeweiligen Einsatzzweck. Beispielsweise genügt write_repository für den Lese- und Schreibzugriff auf alle eigenen Git Repositorien.
• Über die Schaltfläche "Persönliches Zugriffstoken erstellen" wird das Token final erstellt und die generierte Zeichenkette angezeigt, beispielsweise `aztGzZkCT-kGyRs1M6x1`.
  Achtung: Das Token muss nun extern gesichert werden, da es nach Verlassen der Seite nicht mehr angezeigt werden kann.

Die Übersicht aktiver Zugriffstoken zeigt die Namen, Geltungsbereiche und Ablaufdaten zuvor erstellter Token an, nicht aber die Token selbst. Man kann außerdem Token widerrufen/löschen, indem man in der Übersicht beim jeweiligen Token auf das Mülleimer-Symbol klickt.

Zur Authentifikation beim Zugriff über HTTPS nutzt man seinen eigenen Nutzernamen – das ist der Name hinter dem "@", wenn man in der Webübersicht auf seinen Avatar klickt und entspricht in der Regel dem Nutzerkürzel des zentralen ITMZ Nutzerkontos – und ein persönliches Zugriffstoken.

Möchte man mit Git auf eines seiner Projekte zugreifen, beispielsweise zum Klonen oder Synchronisieren, muss das Zugriffstoken mindestens den "write_repository" Geltungsbereich enthalten. In diesem Fall ist die HTTPS Git-URL des Projekts zu nutzen.

Um nicht bei jedem Git Befehl den Nutzernamen und ein Token erneut einfügen zu müssen, kann man den Git Credential Helper einrichten.

Die Voraussetzung ist ein verschlüsselter Speicher, in dem die Anmeldeinformationen sicher abgespeichert werden können. Je nach Betriebssystem wird die Verschlüsselung von unterschiedlichen Hilfsprogrammen realisiert.

Bei Installation des offiziellen Git-Clients unter Windows oder macOS werden sichere Standardeinstellungen gesetzt, die den systemeigenen verschlüsselten Speicher nutzen. Hierzu ist generell keine manuelle Konfiguration nötig. Der Git Credential Manager kann aber auch manuell nachinstalliert werden. Für Linux ist eine zusätzliche Konfiguration nötig. Einsehen und ändern lässt sich das in Git hinterlegte Hilfsprogramm über `git config credential.helper`.

Anstatt sich mittels persönlicher Zugriffstoken über HTTPS zu authentifizieren, kann man mit GitLab auch über eine SSH-Verbindung kommunizieren. Die Daten werden dann über eine verschlüsselte Netzwerkverbindung (Secure Shell) übertragen. Dazu werden sogenannte SSH-Schlüssel (SSH Keys) benötigt. Aus Sicherheitsgründen ist eine SSH-Verbindung mit GitLab auf das Netz der Universität Rostock beschränkt. Nutzer können von unterwegs oder von zuhause also nur auf GitLab über SSH zugreifen, wenn der VPN-Zugang verwendet wird.

SSH setzt mehrere Verschlüsselungs- und Authentifizierungstechniken ein, um sicherzustellen, dass nur autorisierte Teilnehmer miteinander kommunizieren. Vereinfacht gesagt verifiziert sich zuerst der SSH-Server (in diesem Fall GitLab) gegenüber dem Client, indem er ein Zertifikat sendet. Danach muss sich der Client gegenüber dem Server ausweisen. Dies kann unter Verwendung eines Schlüsselpaares, bestehend aus einem öffentlichen Schlüssel (Public Key) und einem privaten Schlüssel (Private Key), erfolgen.

Public Key und Private Key werden individuell auf dem eigenen Computer erzeugt. Der Private Key lässt sich optional mit einem Passwort absichern und sollte stets geheim gehalten werden. Der Public Key wird auf dem Server hinterlegt. Beim Aufbau einer SSH-Verbindung erstellt der Server dann ein kryptografisches Problem mittels dem Public Key und sendet dieses an den Client. Dieser wiederum entschlüsselt das Problem, was ausschließlich mit dem passenden Private Key möglich ist. Dadurch wird eine sichere Verbindung aufgebaut.

Als Voraussetzung wird der OpenSSH Client benötigt, welcher auf den meisten Betriebssystemen aber bereits vorinstalliert ist.

In einer Kommandozeile lässt sich über den Befehl `ssh-keygen -t <TYPE> -b <BITS>` ein Schlüsselpaar erstellen, wobei sich die Art des Schlüssels und die Anzahl der zu verwendeten Bits spezifizieren lässt. Dann wird abgefragt, wo und unter welchem Namen das Schlüsselpaar gespeichert werden soll. Standardmäßig werden sie im Homeverzeichnis im Ordner `.ssh` abgelegt und erhalten die Namen `id_<TYPE>` (Private Key) und `id_<TYPE>.pub` (Public Key). Außerdem lässt sich optional ein Passwort zum Schutz des Private Key setzen. Alternativ lässt man die beiden Eingaben bei der Passphrase leer (nicht empfehlenswert). Entscheidet man sich für ein Passwort, kann man über die Verwendung des `ssh-agent` Tools nachdenken, um zu vermeiden, dass man das Passwort jedes Mal neu eingeben muss. Das Setup vom `ssh-agent` wird hier nicht behandelt.

Folgende SSH-Schlüssel werden auf dem GitLab der Universität Rostock unterstützt:

• ED25519 ist erlaubt und Schlüssel haben eine feste Länge (`-b` flag wird ignoriert):
  ```
  ssh-keygen -t ed25519
  ```
• RSA ist erlaubt, aber Schlüssel müssen mindestens 2048 bits lang sein (besser länger):
  ```
  ssh-keygen -t rsa -b 4096
  ```
• DSA und ECDSA sind nicht erlaubt.

Der Public Key muss nun im Nutzerkonto von GitLab hinterlegt werden. SSH-Schlüssel in GitLab erreicht man, in dem man oben links auf sein Profil klickt und anschließend Einstellungen > SSH-Schlüssel wählt.

[Bild]

Man fügt einen neuen SSH-Schlüssel über die Schaltfläche "Add new key" hinzu:

• Im Textfeld Schlüssel fügt man den Public Key ein, d.h. man kopiert den textuellen Inhalt der Datei `id_ed25519.pub`.
  Dieser sollte in etwa so aussehen:
  ```
  AAAAC3NzaC1lZDI1NTE5AAAAIL1LJAqv+Xazj2kaXZv2KhD78qjvbxH9hIX1Lyo6rqvE user@pc
  ```
• Der Titel ist beliebig und dient später nur der eigenen Übersicht.
• Bei Nutzungstyp können die Zugriffsrechte des Schlüssels gesetzt werden. Entweder zur Authentifizierung beim Projektzugriff oder zum Signieren von Git Commits.
• Optional kann ein Ablaufdatum eingestellt werden.

Die Übersicht aktiver SSH-Schlüssel zeigt die Namen, Key Fingerprints, Nutzungstypen und Ablaufdaten zuvor hinterlegter SSH-Schlüssel an, nicht aber die Schlüssel selbst. Man kann außerdem Schlüssel widerrufen/löschen, indem man in der Übersicht beim jeweiligen Token auf das Mülleimer-Symbol klickt.

Nachdem ein Schlüssel auf GitLab hinterlegt wurden, kann man überprüfen, ob eine SSH-Verbindung korrekt hergestellt werden kann. Dazu verwendet man folgenden Befehl auf der Kommandozeile:

```

ssh -T git@gitlab.uni-rostock.de

```

Ist das die erste Verbindung, erhält man vermutlich folgende Nachricht:

```

The authenticity of host 'gitlab.uni-rostock.de (139.30.22.169)' can't be established.

ED25519 key fingerprint is SHA256:hTAshNmqmCJ6qJV8iAQmDKMTvsWABJupjGLJ7UtpwcM. This key is not known by any other names

Are you sure you want to continue connecting (yes/no/[fingerprint])?

```

Anhand des Key Fingerprint, lässt sich die Authentizität des Servers überprüfen. Die SSH Key Fingerprints vom GitLab der Universität Rostock sind hier zu finden. Die Frage bei der Eingabe bestätigt man mit “yes”.

Hat alles korrekt funktioniert, erscheint eine Willkommensnachricht "Welcome to GitLab, @username!".

Beim Arbeiten mit einem Repository verwendet man die SSH Git-URL.

Die Eingabe eines Nutzernamens oder Zugriffstokens ist nicht notwendig. Wurde der private Schlüssel allerdings durch ein Passwort gesichert, muss dieses zur Authentifizierung eingegeben werden.

Neue Projekte können entweder direkt in der Weboberfläche von GitLab erstellt werden oder man verwendet die Kommandozeile um ein lokales Repository zu einem neuen GitLab Projekt hinzuzufügen.

Ein neues Projekt kann über die Schaltfläche "Neues Projekt/Repository", unter dem "+" Symbol im Seitenmenü, erstellt werden.

Bei einem leeren Projekt muss ein Projektname vergeben werden. Die Projekt-URL wird automatisch aus diesem Namen generiert, kann aber auch manuell angepasst werden. Außerdem muss eine Sichtbarkeitsstufe (siehe unten Sichtbarkeit von Projekten) gewählt werden. Weiterhin sollte das Projekt mit einer README Datei initialisiert werden, damit das Repository direkt geklont werden kann.

Anstelle eines leeren Projekts kann man auch aus verschiedenen Projekt-Vorlagen auswählen, um das Projekt mit passenden Dateien zu initialisieren. Dafür bietet GitLab integrierte Vorlagen für viele Programmiersprachen an.

Ein Projekt über die Kommandozeile mit Git zu erstellen ergibt Sinn, falls man bereits über ein lokales Repository verfügt und dieses in ein neues GitLab Projekt hinzufügen möchte.

Dafür verwendet man ein `git push`, um das lokale Repository zu GitLab hochzuladen. Gleichzeitig erzeugt GitLab das zugehörige Projekt in dem gewünschten Namensraum (z.B. als persönliches Projekt oder innerhalb einer Gruppe). Dabei ist zu beachten, dass diese Variante nicht für Projekte verwendet werden kann, deren Projekt-Pfade bereits existieren oder umbenannt wurden. Es müssen stets einzigartige Projekt-Pfade verwendet werden. Außerdem muss man über die nötigen Berechtigungen zum Hinzufügen neuer Projekte im jeweiligen Namensraum verfügen.

• Sie haben noch kein lokales Projekt? Verwenden Sie alle Schritte (1) bis (7).
• Sie haben ein lokales Projekt, aber es wird noch nicht mit Git verwaltet? Verwenden Sie die Schritte (2), (3), (5), (6), (7).
• Sie haben ein lokales Git Repository? Verwenden Sie die Schritte (2), (6), (7).

Für das Beispiel fügen wir ein neues persönliches Projekt mit dem Namen `project_name` für den Account `user_name` hinzu. In der Praxis müssen diese Platzhalter entsprechend ersetzt werden.

1. Ordner für das Projekt erstellen:
   ```
   mkdir project_name
   ```
2. Ordner für das Projekt betreten:
   ```
   cd project_name
   ```
3. Git Repository initialisieren:
   ```
   git init
   ```
4. Einige Dateien anlegen:
   ```
   echo 'Project Name' > README.md
   ```
5. Die Dateien dem Git Repository hinzufügen:
   ```
   git add .
   git commit -m "Initial commit"
   ```
6. Das externe Repository festlegen:
   • Für HTTPS:
     ```
     git remote add origin gitlab.uni-rostock.de/user_name/project_name.git
     ```
   • Für SSH:
     ```
     git remote add origin git@gitlab.uni-rostock.de:user_name/project_name.git
     ```
7. Projekt zu GitLab senden:
   ```
   git push -u origin main
   ```

Zum Klonen des Projekts wird die Git-URL benötigt, welche man unter der Schaltfläche “Code” in der Projektübersicht findet und dort kopieren kann. Je nach Art der Authentifizierung, die man verwenden möchte, wählt man HTTPS oder SSH.

Auf der Kommandozeile navigiert man nun zum gewünschten Speicherort des Projekts und gibt `git clone`, gefolgt von der jeweiligen Git-URL, ein und authentifiziert sich. In diesem Fall wählen wir HTTPS und würden uns mittels eines persönlichen Zugriffstokens authentifizieren. Danach lässt sich lokal mit dem Repository arbeiten.

```

git clone gitlab.uni-rostock.de/namespace/project.git

```

Bereits existierende Projekte können in GitLab importiert werden. Dafür stehen mehrere Möglichkeiten zur Auswahl. Man kann entweder die Import/Export-Funktionalität zur Migration von Projekten zwischen verschiedenen GitLab Instanzen nutzen, Projekte von GitHub importieren, oder ein beliebiges Git Repository direkt über die Git-URL importieren.

Projekte in GitLab können als Archiv exportiert und anschließend in einer anderen GitLab Instanz importiert werden. Bei dieser Variante werden viele, aber nicht alle Metadaten eines Projekts übernommen.

Der Projekt-Export ist in den allgemeinen Projekteinstellungen zu finden. Dazu öffnet man das gewünschte Projekt und wählt "Einstellungen > Allgemein" im Seitenmenü. Anschließend öffnet man das Untermenü "Erweitert" und wählt die Schaltfläche "Projekt exportieren". Sobald der Export generiert wurde, erhält man eine Email mit dem Download-Link zum Archiv, welcher 24 Stunden gültig ist. Alternativ kann man die Website der Projekteinstellungen erneut aufrufen, wo nun eine neue Schaltfläche "Export herunterladen" verfügbar sein sollte.

Für den Projekt-Import wählt man bei der Erstellung eines neuen Projektes die Variante "Projekt importieren" und anschließend "GitLab-Export".

Hier gibt man dem Projekt einen Namen und kann optional die Projekt-URL anpassen. Über die Schaltfläche "Choose File" wählt man das gewünschte Archiv zum Importieren aus. Es wird nur das Format `.tar.gz` unterstützt. Letztlich startet man den Import-Prozess mit der Schaltfläche "Projekt importieren".

Mit dieser Methode können Projekte von github.com importiert werden. Möchte man Projekte von einer anderen GitHub Instanz importieren, muss stattdessen die GitLab API verwendet werden. Neben dem Git Repository selbst, werden eine Menge an Metadaten mit importiert.

Bei der Erstellung eines neuen Projekts wählt man "Projekt importieren" und anschließend "GitHub".

Nun muss man sich mit einem persönlichen GitHub Zugriffstoken authentifizieren, welches man zuvor auf GitHub generiert hat. Anschließend kann man aus allen Projekten auswählen, auf die der Account Zugriff hat. Es lassen sich einzelne Projekte importieren über die Schaltfläche "Importieren" hinter jedem Projekt, oder man importiert mehrere Projekte auf einmal mit der Schaltfläche "X Repositorys importieren", nachdem man diese gegebenenfalls nach Namen oder Zugehörigkeit gefiltert hat. Außerdem kann man kann auch den Namensraum und Projektnamen vor dem Import anpassen.

Um ein anderes Zugriffstoken für GitHub zu verwenden, kann man sich entweder aus GitLab aus- und wieder einloggen, oder man widerruft das alte Token auf GitHub.

Bei dieser Variante wird ausschließlich das Git Repository importiert. Andere Projektdaten wie Tickets oder Merge Requests können nicht importiert werden.

Bei der Erstellung eines neuen Projekts wählt man “Projekt importieren” und anschließend “Repository nach URL”.

Hier fügt man die Git-URL des bestehenden Repository ein. Falls es sich nicht um ein öffentliches Repository handelt, muss man zugehörige Daten zur Authentifizierung eingeben. Des Weiteren vergibt man einen Projektnamen und kann optional die Projekt-URL, Beschreibung oder das Sichtbarkeitslevel anpassen. Über die Schaltfläche "Projekt anlegen" startet man den Import-Prozess.

Jedes Projekt gehört einer der Sichtbarkeitsstufen privat, intern oder öffentlich an, die angibt, welcher Personenkreis das Projekt einsehen und klonen kann:

• Private Projekte sind nur für die Mitglieder des Projekts einsehbar.
• Interne Projekte sind für alle Personen mit einem GitLab Nutzerkonto einsehbar, die angemeldet sind. Dies umfasst alle Personen mit einem gültigen zentralen ITMZ Nutzungskonto. Ausgenommen sind externe Personen, für die zu Kollaborationszwecken manuell ein GitLab Account angelegt wurde.
• Öffentliche Projekte sind für alle Personen einsehbar, selbst externe Nutzer oder solche ohne Nutzerkonto.

Sichtbarkeitsstufen haben keine Auswirkung auf die Sichtbarkeit von direkten Mitgliedern innerhalb eines Projekts. Projektmitglieder können stets alle anderen Mitglieder einsehen und wer diese eingeladen hat. Nur Nutzer mit der Rolle "Owner" können die Sichtbarkeitsstufe eines Projekts ändern (siehe unten Nutzerrollen in Projekten).

Um die Sichtbarkeitsstufe eines Projekts zu ändern, öffnet man das gewünschte Projekt und wählt "Einstellungen > Allgemein" im Seitenmenü. Anschließend öffnet man das Untermenü "Sichtbarkeit, Funktionen, Berechtigungen" und kann dort die Projekt-Sichtbarkeit setzen. Außerdem können hier einzelne Feature des Projekts ein- und ausgeschaltet werden.

Projektmitglieder lassen sich über die Projektansicht "Verwalten > Mitglieder" im Seitenmenü eines Projekts verwalten. Hier lassen sich neue Mitglieder einladen, Rollenberechtigungen verteilen und Mitglieder entfernen. Ausschließlich Projektmitglieder der Rollen Maintainer oder Owner können Projektmitglieder verwalten. Außerdem kann ein Maintainer keine Änderungen der Rolle Owner durchführen.

Zum Hinzufügen von Einzelpersonen wählt man die Schaltfläche "Mitglieder einladen". Unter "Username or name" lässt sich nach Nutzern innerhalb von GitLab suchen. Es ist zu beachten, dass Mitglieder nicht über die Email-Adresse eingeladen werden können, da GitLab-Accounts intern über das universitäre Nutzerkürzel verknüpft sind. Des Weiteren muss sich ein Nutzer mindestens einmal vorher bei GitLab eingeloggt haben, damit der zugehörige Account erstellt und somit auffindbar ist. Beim Einladen muss dem Nutzer eine Rolle (siehe oben Nutzerrollen in Projekten) zugewiesen werden. Optional lässt sich der Zugriff auch zeitlich beschränken. Über die Schaltfläche "Einladen" wird der Nutzer Mitglied des Projekts.

Alternativ lassen sich auch die direkten Mitglieder eines anderen Projekts importieren, über die Schaltfläche "Aus einem Projekt importieren". Dabei werden die ursprünglich vergebenen Rollen beibehalten.

Eine weitere Möglichkeit ist, eine ganze Gruppe (siehe unten Gruppen) als Projektmitglied hinzuzufügen, über die Schaltfläche "Gruppe einladen". Man vergibt der Gruppe eine maximale Rolle und optional ein Ablaufdatum des Zugriffs. Die eigentlichen Rollen der Gruppenmitglieder im Projekt übertragen sich dabei aus den Rollen in der Gruppe. Wird beispielsweise eine Gruppe als Maintainer eingeladen, aber ein Gruppenmitglied hat innerhalb der Gruppe nur die Rolle Guest, so behält diese Person die Rolle Guest auch im Projekt.

Handelt es sich um ein internes oder öffentliches Projekt, haben Nutzer die Möglichkeit selbst Zugriff auf das Projekt anzufragen. Dazu öffnet man das Aktionsmenü (3 Punkte) in der Projektübersicht und wählt "Zugriff anfragen". Damit wird eine Email-Anfrage an aktive Projektmitglieder der Rollen Maintainer und Owner gesendet, welche die Anfrage an- oder ablehnen können. Diese Funktionalität kann in den allgemeinen Projekteinstellungen unter "Sichtbarkeit, Funktionen, Berechtigungen > Projekt-Sichtbarkeit > Benutzer(innen) können Zugriff anfordern" umgestellt werden.

Zum Entfernen von Projektmitgliedern öffnet man die Mitgliederübersicht. Neben dem jeweiligen Mitglied öffnet man das Aktionsmenü (3 Punkte) und wählt "Mitglied entfernen". An dieser Stelle kann man den Nutzer optional auch von allen zugehörigen Tickets und Merge Requests entfernen.

Weiterführende Informationen zur Verwaltung von Projekten sind der offiziellen Dokumentation zu entnehmen.

GitLab Gruppen können genutzt werden, um mehrere Projekte und Personen zu organisieren. Mitglieder einer Gruppe haben Zugriff auf alle Projekte innerhalb der Gruppe und die Zugriffsrechte können zentral über die Gruppe verwaltet werden. Außerdem können Untergruppen erstellt werden.

Analog zur Sichtbarkeit von Projekten (siehe oben Sichtbarkeit von Projekten), können Gruppen privat, intern oder öffentlich sein, mit den daraus resultierenden Zugriffsrechten. Die Sichtbarkeitsstufe der Gruppe vererbt sich standardmäßig auf alle Gruppenprojekte, kann aber auch individuell gesetzt werden, wobei ein Gruppenprojekt nie eine höhere Sichtbarkeitsstufe haben kann als die übergeordnete Gruppe.

Ebenso ist die Rollenvergabe bei Gruppen analog zu der in Projekten strukturiert. Es gibt in gestaffelter Reihenfolge, mit zunehmenden Zugriffsrechten: Guest, Reporter, Developer, Maintainer und Owner:

• Guests können eine Gruppe nur einsehen, aber nichts verändern.
• Reporter können zusätzlich die Gruppen-Label verwalten.
• Developer können zusätzlich Projekte in der Gruppe anlegen sowie Meilensteine der Gruppe verwalten.
• Maintainer können zusätzlich Untergruppen anlegen.
• Owners können zusätzlich die Gruppeneinstellungen ändern, Gruppenmitglieder verwalten, die Gruppe löschen, die Audit Events der Gruppe einsehen und Benachrichtigungs-Emails ausschalten.

Eine detaillierte Übersicht aller Rollenberechtigungen in Gruppen ist in der offiziellen Dokumentation aufgeführt.

Die Gruppenrolle eines Mitglieds vererbt sich automatisch auf die Rolle innerhalb aller Gruppenprojekte, kann jedoch auch projektspezifisch gesetzt werden. Außerdem können einzelne Nutzer auch von außerhalb der Gruppe als Projektmitglied zu individuellen Gruppenprojekten hinzugefügt werden.

Eine neue Gruppe kann über die Schaltfläche "Neue Gruppe", unter dem "+" Symbol im Seitenmenü, erstellt werden.

Bei einer neuen Gruppe muss ein Gruppenname vergeben werden. Die Gruppen-URL wird automatisch aus diesem Namen generiert, kann aber auch manuell angepasst werden. Außerdem muss eine Sichtbarkeitsstufe gewählt werden.

Achtung: Das Einladen von Gruppenmitgliedern über Email beim Erstellen der Gruppe wird nicht unterstützt. Stattdessen sollte die Gruppe zunächst ohne Mitglieder erstellt werden. Anschließend können Nutzer über die Gruppenverwaltung eingeladen werden.

Gruppenmitglieder lassen sich über die Gruppenansicht "Verwalten > Mitglieder" im Seitenmenü einer Gruppe verwalten. Hier lassen sich neue Mitglieder einladen, Rollenberechtigungen verteilen und Mitglieder entfernen. Ausschließlich Gruppenmitglieder der Rolle Owner können Gruppenmitglieder verwalten.

Zum Hinzufügen von Einzelpersonen wählt man die Schaltfläche "Mitglieder einladen". Unter "Username or name" lässt sich nach Nutzern innerhalb von GitLab suchen. Es ist zu beachten, dass Mitglieder nicht über die Email-Adresse eingeladen werden können, da GitLab-Accounts intern über das universitäre Nutzerkürzel verknüpft sind. Des Weiteren muss sich ein Nutzer mindestens einmal vorher bei GitLab eingeloggt haben, damit der zugehörige Account erstellt und somit auffindbar ist. Beim Einladen muss dem Nutzer eine Rolle (siehe oben Sichtbarkeit und Rollen in Gruppen) zugewiesen werden. Optional lässt sich der Zugriff auch zeitlich beschränken. Über die Schaltfläche "Einladen" wird der Nutzer Mitglied des Projekts.

Eine weitere Möglichkeit ist, eine ganze Gruppe als Gruppenmitglied hinzuzufügen, über die Schaltfläche "Gruppe einladen". Man vergibt der Gruppe eine maximale Rolle und optional ein Ablaufdatum des Zugriffs. Die eigentlichen Rollen der neu hinzugefügten Gruppenmitglieder übertragen sich dabei aus den Rollen in der ursprünglichen Gruppe. Wird beispielsweise eine Gruppe als Maintainer eingeladen, aber ein Gruppenmitglied hat innerhalb der ursprünglichen Gruppe nur die Rolle Guest, so behält diese Person die Rolle Guest bei.

Handelt es sich um eine interne oder öffentliche Gruppe, haben Nutzer die Möglichkeit selbst Zugriff auf die Gruppe anzufragen. Dazu öffnet man das Aktionsmenü (3 Punkte) in der Gruppenübersicht und wählt "Zugriff anfragen". Damit wird eine Email-Anfrage an aktive Gruppenmitglieder der Rolle Owner gesendet, welche die Anfrage an- oder ablehnen können. Diese Funktionalität kann in den allgemeinen Gruppeneinstellungen unter "Berechtigungen und Gruppenfunktionen > Mitgliedschaft > Benutzer(innen) können Zugriff anfordern" umgestellt werden.

Zum Entfernen von Gruppenmitgliedern öffnet man die Mitgliederübersicht. Neben dem jeweiligen Mitglied öffnet man das Aktionsmenü (3 Punkte) und wählt "Mitglied entfernen". An dieser Stelle kann man den Nutzer optional auch von allen zugehörigen Untergruppen, Projekten, Tickets und Merge Requests entfernen.

Weiterführende Informationen zum Umgang mit Gruppen sind der offiziellen Dokumentation zu entnehmen.

Falls ein Projekt große oder eine hohe Anzahl an Dateien enthält, kann das zugehörige Git Repository sehr groß werden. Das hat negative Auswirkungen auf die Git Performance, den verfügbaren Speicherplatz und die generelle Serverauslastung. Insbesondere wenn mit Binärdateien gearbeitet wird, aber vergessen wurde Git LFS einzurichten, kann es vorkommen, dass die Größe eines Projekts reduziert werden muss. Als Faustregel gilt: Ist das Repository größer als 1 GB ohne Git LFS, sollte die Größe reduziert werden.

Die Größe eines Projekts kann oben auf der Projektseite in GitLab abgelesen werden (Projektspeicher). Der Wert zeigt die Gesamtgröße des Projekts, einschließlich der Artefakte, LFS, Pakete, Code-Schnipsel und Wiki an. Über einen Klick auf den Text Projektspeicher kann eine detaillierte Übersicht aufgerufen werden. Bitte beachten Sie, dass die Werte zwischengespeichert werden und daher möglicherweise nicht sofort die tatsächliche Größe widerspiegeln, kurz nachdem Änderungen im Projekt vorgenommen wurden.

Leider reicht es nicht einfach aus, bestimmte Dateien im Projektverzeichnis zu löschen. Das verringert die Größe des Repository nicht, da die alten Versionen der Dateien immer noch in der Historie von Git verwaltet werden. Im Folgenden werden einige Varianten vorgestellt, wie sich die Projektgröße dennoch reduzieren lässt. Mit steigendem Aufwand können dabei mehr Informationen des Projekts erhalten werden.

Die einfachste Möglichkeit ist ein neues Projekt zu erstellen, nicht mehr benötigte Dateien zu löschen und sicherzustellen, dass Binärdateien über Git LFS verwaltet werden.

Achtung: Diese Variante erhält nicht die Historie der Dateien (inklusive Commit Nachrichten und Branches), sondern ausschließlich den aktuellen Stand des Repository. Außerdem gehen alle weiteren GitLab-spezifischen Daten verloren, wie z.B. Tickets, Wiki und Code-Schnipsel.

1. Ein neues leeres Projekt auf GitLab anlegen.
2. Das Projekt lokal klonen:
   ```
   git clone gitlab.uni-rostock.de/username/new-project-with-lfs.git
   ```
3. Alle relevanten Dateien vom alten Projekt ins neue Projekt kopieren (ohne das `.git/` Verzeichnis).
4. Git LFS initialisieren und Binärdateien verwalten lassen:
   ```
   git lfs install
   git lfs track '*.jpg'
   git lfs track '*.zip'
   git lfs track 'my_binary_data_file'
   ... additional git lfs track commands
   ```
5. Das GitLab Repository updaten:
   ```
   git add .
   git commit -m "Initial commit"
   git push
   ```
6. Wenn alles geklappt hat und der gewünschte Stand im neuen Projekt vorhanden ist, kann das alte Projekt gelöscht werden.

In dieser komplexeren Variante wird auch ein neues Projekt erstellt, aber die Historie des alten Repository in verändertem Zustand mit übernommen. Dazu werden Werkzeugen wie git-filter-repo oder BFG Repo-Cleaner genutzt.

Der Vorteil ist, dass Textdateien mit ihrer gesamten Historie erhalten werden können, während alte Versionen großer Binärdateien gelöscht werden. Die exakte Vorgehensweise hängt von der Projektstruktur ab. Nutzer, die diese Variante verfolgen wollen, sollte sich vorher mit den Befehlen und der Funktionsweise der Tools auseinandersetzen. Im Folgenden wird ein Beispiel gezeigt, wie das Vorgehen aussehen könnte.

Achtung:  Diese Variante erhält nur die veränderte Historie des Repository. GitLab-spezifische Daten, wie z.b. Tickets, Wiki und Code-Schnipsel, gehen verloren.

1. Ein neues leeres Projekt auf GitLab anlegen.
2. Das alte Repository in neues Verzeichnis klonen mit der Option `--mirror`:
   ```
   git clone --mirror gitlab.uni-rostock.de/username/the-big-project.git
   ```
   Hinweis: Falls das Projekt bereits Git LFS Dateien enthält, werden diese hier nicht mit geklont und müssen in Schritt 6 manuell hinzugefügt werden.
3. Ausgewählte Binärdateien und Verzeichnisse mit `git-filter-repo` oder `bfg` löschen. In diesem Beispiel werden sowohl `.jpg` und `.zip` Dateien aus der Historie gelöscht als auch das `data/` Verzeichnis:
   ```
   cd the-big-project
   git-filter-repo --use-base-name --path-glob '*.jpg' --path-glob '*.zip' --invert-paths
   git-filter-repo --path data/ --invert-paths
   ```
4. Das modifizierte Repository ins neu angelegte Projekt hochladen:
   ```
   git push --mirror gitlab.uni-rostock.de/username/new-project-with-lfs.git
   ```
5. Das neue Repository in ein neues Verzeichnis klonen (ohne die Option `--mirror`):
   ```
   cd ..
   git clone gitlab.uni-rostock.de/username/new-project-with-lfs.git
   cd new-project-with-lfs
   ```
6. Ausgewählte Binärdateien und Verzeichnisse vom alten ins neue Repository kopieren (ohne das `.git/` Verzeichnis und Dateien, die bereits im neuen Repository vorliegen).
7. Git LFS initialisieren und Binärdateien verwalten lassen:
   ```
   git lfs install
   git lfs track '*.jpg'
   git lfs track '*.zip'
   git lfs track 'my_binary_data_file'
   ... additional git lfs track commands
   ```
   Hinweis: Falls mehrere Branches im Repository existieren, muss Git LFS in allen Branches korrekt initialisiert werden.
8. Das GitLab Repository updaten:
   ```
   git add .
   git commit -m "Adds some data files"
   git push
   ```
9. Wenn alles geklappt hat und der gewünschte Stand im neuen Projekt vorhanden ist, kann das alte Projekt gelöscht werden.

In der offiziellen GitLab Dokumentation wird eine Variante beschrieben, bei der das ursprüngliche Projekt erhalten bleibt (inklusive der GitLab-spezifischen Daten) und gleichzeitig die Repository Historie umgeschrieben wird. Dieses Vorgehen ist recht umfangreich und kompliziert, aber gut dokumentiert.

Es ist wichtig, dass nach Änderung des Projekts alle Projektmitglieder ihre lokalen Kopien des Repository löschen und neu klonen. Andernfalls wird die alte Historie beim nächsten Synchronisieren wieder hochgeladen.