Page tree

Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Deutsch  English


German

Was passiert mit Projekten von gelöschten Kennungen?

Wird die Kennung eines Benutzers gelöscht, wird dieser Benutzer auch für GitLab gesperrt. Projekte und Gruppen, die diesem Benutzer gehören, werden im GitLab noch für sechs Monate erhalten. Danach werden sie endgültig gelöscht.

Wenn eine oder mehrere Gruppen oder Projekte des Benutzers weiterhin aktiv bleiben sollen, müssen sie vor der Löschung der Kennung einem anderen aktiven GitLab-Benutzer übertragen werden. 

Um eine Gruppe weiterhin aktiv zu halten, wird einfach ein weiterer Benutzer in der Mitgliedsliste der Gruppe als Besitzer (Owner) eingetragen. Dasselbe gilt für Projekte innerhalb der Gruppe: bitte in jedem Projekt mindestens einen weiterhin aktiven Benutzer als Besitzer (Owner) eintragen.

Wenn ein persönliches Projekt des Benutzers weiterhin aktiv bleiben soll, empfehlen wir das Projekt in eine Gruppe zu verschieben, die auch speziell zu diesem Zweck erstellt werden kann. Die Übertragung erfolgt in den erweiterten Einstellungen des Projekts (Project Settings → General → Advanced → Transfer Project). Danach den weiterhin aktiven GitLab-Benutzer als einer der Besitzer (Owner) in der Gruppe und im Projekt eintragen. Alternativ kann das Projekt auch exportiert werden (Project Settings → General → Advanced → Export Project) und an den weiterhin aktiven GitLab-Benutzer weitergeben werden , um das Projekt zu importieren (New Project → Import Project → Import Project from GitLab export).

Vor allem für öffentliche Projekte empfehlen wir die Projekte in Gruppen einzuordnen.

Werden Projekte gesichert? Wie kann ich ein gelöschtes Projekt wiederherstellen?

Das LRZ erzeugt tägliche Backups der kompletten GitLab-Instanz. Diese Backups werden dediziert gelagert und regelmäßig auf Integrität überprüft. Die Backups dienen allerdings nur dazu, GitLab nach einem kritischen Fehler wiederherzustellen. Dabei wird die komplette GitLab-Instanz auf den Zeitpunkt des Backups zurückgesetzt. Eine Wiederherstellung einzelner Projekte im laufenden Betrieb ist derzeit nicht möglich.

Eine Wiederherstellung von Repositories, die vom Benutzer selbst gelöscht wurden, ist innerhalb von sieben Tagen möglich, sofern das Projekt bereits einmal im Backup vorhanden ist. Dabei kann allerdings nur das Git-Repository wiederhergestellt werden – alle Issues, Merge Requests und Snippets können nach dem Löschen des Projekts nicht wiederhergestellt werden.

Wie lautet der SSH-Key-Fingerprint von GitLab?

Wenn Sie das erste Mal über ein Terminal/eine Eingabeaufforderung auf Ihrem PC Kontakt mit GitLab aufnehmen (z.B. wenn Sie ein Projekt klonen oder Änderungen ins Repository schreiben möchten), werden Sie wahrscheinlich nach der Authentizität des Hosts gefragt, mit dem Sie sich verbinden möchten. Die Fingerprints des LRZ GitLab finden Sie auf dessen Instanzkonfigurationsseite.

Anchor
GitInvited
GitInvited

Kann ich mit Personen auf GitLab zusammenarbeiten, die über keine entsprechende Kennung verfügen?

Ja, dies ist möglich mit GitInvited.

GitInvited wurde entwickelt, um externen Kooperationspartnern ebenfalls einen GitLab-Zugang geben zu können. Dabei hat jeder Benutzer, der sich mithilfe eines LDAP-Accounts (z.B. LRZ-, TUM- oder LMU-Kennung) in GitLab eingeloggt hat, ein Kontingent von 20 Einladungen. Diese Einladungen können über GitInvited an beliebige E-Mail-Adressen versendet werden. Die E-Mail-Adresse darf dabei noch nicht in GitLab registriert sein.

Benutzerkontos die durch diese Methode erstellt sind, haben den Status extern in LRZ GitLab. Das bedeutet unter anderem, dass sie keine Gruppen oder eigene Projekte erstellen können. Siehe GitLab Permissions Dokumentation für Details.

Der Benutzer, der die Einladung versendet hat (im weiteren Verlauf "Parent User" genannt), wird in der GitInvited-Datenbank mit dem eingeladenen Benutzer ("Child User") verknüpft. So hat das LRZ auch für diese externen Benutzer immer einen Ansprechpartner.

Falls ein Parent User in GitLab geblockt wird (z.B. weil seine Kennung abgelaufen ist), werden alle Child User, für die er verantwortlich ist, ebenfalls geblockt. Um dies zu verhindern, müssen diese Benutzer zu einem neuen Parent User migriert werden. Dies kann nur von den Administratoren durchgeführt werden. Bitten Sie den neuen Parent User sich an den LRZ Servicedesk zu wenden.

Obwohl GitInvited und GitLab unter verschiedenen URLs erreichbar sind, findet eine Kommunikation beider Dienste untereinander statt. Beim erstmaligen Login kommt es daher vor, dass man im Zuge des OAuth-Login-Verfahrens zwischen den Anwendungen weitergeleitet wird.

Anchor

Repo

Repository_verkleinern

Repo

Repository_verkleinern

Wie kann ich mein Repository verkleinern?

Vor allem mit großen oder sehr dynamischen Dateien können Git-Repositories groß werden. Das hat nicht nur Auswirkung auf dem Speicherplatz und Download-Zeiten, sondern verursacht zusätzliche Last auf unseren Servern. Insbesondere wenn man mit binären Dateien arbeitet und vergessen hat, sie mit Git Large File Storage (LFS) zu verwalten, ist die Verkleinerung des Repositorys oft nötig. Die Größe des Projekts inklusive Repository und LFS-Dateien wird auf der Projekt-Seite gezeigt. Grundregel: Wenn das Repository ohne Git LFS größer als 1 GB ist, soll es verkleinert werden.

Es reicht leider nicht, unnötige Dateien im Projekt-Verzeichnis einfach zu löschen. Dadurch wird das Repository nicht kleiner, weil die alten Versionen der Dateien weiterhin im Git verwaltet sind.

Methode 1: Das Projekt neu erstellen

Die einfachste und in den meisten Fällen empfohlene Methode ist eine Neuerstellung des Projektes, mit LFS-Verwaltung für binäre Dateien:

  1. Neues leeres Projekt erstellen (New Project → Blank project → <Projektname angeben und "Initialize repository with a README" ankreuzen>)
  2. Das neue Projekt klonen:
    git clone https://gitlab.lrz.de/username/new-project-with-lfs.git
    (oder durch SSH: git clone git@gitlab.lrz.de:username/new-project-with-lfs.git)
  3. Dateien aus dem alten Projekt ins neue Projekt kopieren (ohne das Verzeichis .git/)
  4. Git LFS initialisieren und LFS Tracking für binäre Dateien aktivieren:
    git lfs install
    git lfs track '*.jpg'
    git lfs track '*.zip'
    git lfs track 'my_binary_data_file'
    ... weitere lfs track Kommandos für mehr Dateien und Dateitypen falls nötig ...

  5. Dateien ins GitLab hochladen:
    git add .
    git commit -m "Initial commit"
    git push

  6. Das alte Projekt löschen (Settings → General → Advanced → Remove project) 

Mit dieser Methode bleiben die alten Versionen der Dateien und dazugehörende Commit-Nachrichten, Branches, Issues usw. nicht erhalten. 

Methode 2: Die Versionsdateien umschreiben (history rewrite)

Falls die Verfügbarkeit der alten Versionen der Dateien, Commit-Nachrichten und/oder Branches des Projektes wichtig sind, kann diese etwas aufwändigere Methode verwendet werden. Es handelt sich um ein teilweises Umschreiben der Versionsdateien (history rewrite) mit Tools wie git-filter-repo oder BFG Repo Cleaner. So können beispielsweise Quellcode-Dateien mit ihrer gesamten Versionierung erhalten bleiben und nur alte Versionen der großen binären Dateien gelöscht werden. Die Einzelheiten in der Nutzung dieser Tools sind davon abhängig, wie die Dateien im Projekt organisiert sind. Unten ist ein Beispiel wie die Schritte bei dieser Methode ausschauen können:

  1. Das bestehende Projekt mit Option "mirror" klonen
    git clone --mirror https://gitlab.lrz.de/username/the-big-project.git
    (oder durch SSH: git clone --mirror git@gitlab.lrz.de:username/the-big-project.git)
  2. Mit git-filter-repo ausgewählte Dateien und Verzeichnisse löschen. In unserem Beispiel wird der Inhalt der Verzeichnis data sowie jpg- und zip-Dateien aus dem Projekt und dessen History entfernt. Für Einzelheiten bitte die Dokumentation der Tools konsultieren.
    cd the-big-project.git
    git-filter-repo --use-base-name --path-glob '*.jpg' --path-glob '*.zip' --invert-paths
    git-filter-repo --path data/ --invert-paths
  3. Das verkleinerte Repository in ein neues Projekt hochladen
    git push --mirror https://gitlab.lrz.de/username/new-project-with-lfs.git
    Das neue Projekt klonen (ohne Option "mirror"):
  4. cd ..
    git clone https://gitlab.lrz.de/username/new-project-with-lfs.git
    cd new-project-with-lfs
  5. Ausgewählte binäre Dateien und Verzeichnisse aus dem alten Projekt in das neue Projekt kopieren (ohne das Verzeichis .git/ und die Dateien die im neuen Projekt bereits vorhanden sind).
  6. Git LFS initialisieren und LFS Tracking für binäre Dateien aktivieren:
    git lfs install
    git lfs track '*.jpg'
    git lfs track '*.zip'
    git lfs track 'my_binary_data_file'
    ... weitere lfs track Kommandos für mehr Dateien und Dateitypen falls nötig ...
    Hinweis: Falls Sie mehrere Branches im Ihrem Repository haben, bitte sicherstellen dass Git LFS in allen Branches ordnungsgemäß initialisiert wird.
  7. Dateien ins GitLab hochladen:
    git add .
    git commit -m "Adds some data files"
    git push
  8. Das alte Projekt löschen (Settings → General → Advanced → Remove project)

Mit dieser Methode bleiben die Versionierung der Dateien, Branches und Tags erhalten. Branch Requests auf der GitLab Web-Oberfläche gehen verloren, aber weil Branches weiterhin vorhanden sind können neue Branch Requests leicht erstellt werden. Issues, Kommentare, Snippets und andere Inhalte die nicht ein Teil der Git-Repository selber sondern im GitLab-Datenbank gespeichert sind bleiben nicht erhalten.

Issues können separat als CSV-Datei exportiert und wieder im neuen Projekt importiert werden. Kommentare in den Issues bleiben allerdings nicht erhalten.

Wichtig: Auch mit dieser Methode bitte ein neues Projekt mit einem neuen Pfad erstellen und das verkleinerte Repository dort pushen. Sonst bleiben die alten Versionen der Dateien noch als interne Referenzen auf dem Server erhalten.

(Für fortgeschrittene Nutzer gibt es eine auf der GitLab-Seite beschriebene Methode, innerhalb des Projektes nur die Repository umzuschreiben und damit alle weiteren Daten wie Issues, Kommentare usw. und der ursprüngliche Pfad zu erhalten. Sie ist relativ kompliziert und wir empfehlen sie nur, wenn Sie mit Git und GitLab gut vertraut sind. Falls Sie diese Methode probieren möchten, bitte sicherstellen dass alle Schritte, inklusive das Repository Cleanup mit der commit.map-Datei, durchgeführt werden. Außerdem ist es wichtig, dass alle Mitglieder des Projekts nach dem Verkleinern ihre lokale Kopien löschen und das Projekt neu klonen. Sonst wird beim nächsten git push das alte unveränderte History ins Projekt hochgeladen was zu einem Chaos führt.)


English

What happens to projects of deleted User IDs?

When a user's ID is deleted, the user will also be locked out of GitLab and will not be able to log in again. Projects and groups that belong to this user are still preserved for six months in GitLab. After that, they are permanently deleted.

If one or more groups or projects of the user are to remain active, they must be transferred to another active GitLab user before the User ID is deleted.

In order to keep a group active, simply enter another user in the member list of the group with the role owner. The same applies to projects within the group: please enter at least one active user as owner in each project.

If a user's personal project is to remain active, we recommend moving the project to a group. The group can also be created specifically for this purpose. The transfer takes place in the advanced settings of the project (Project Settings → General → Advanced → Transfer Project). After moving the project to the group, please enter the still active GitLab user as one of the owners in the group and the project. Alternatively, the project can be exported (Project Settings → General → Advanced → Export Project) and passed on to the still active GitLab user who can import the project (New Project → Import Project → Import Project from GitLab export).

Especially in the case of public projects we recommend organizing the projects into groups.

Are projects backed up? How can I recover a deleted project?

LRZ generates daily backups of the complete GitLab instance. These backups are stored on a separate storage system and regularly checked for integrity. However, these backups only serve to restore GitLab after a critical error. The entire GitLab instance is reset to the time of the backup. Restoring individual projects during operation is currently not possible.

Recovering repositories that have been deleted by the user is possible within seven days, provided the project already exists in the backup. However, only the Git repository itself can be restored, whereas issues, merge requests and snippets will be lost after deleting the project.

What is the SSH key fingerprint of GitLab?

The first time you connect to GitLab from a terminal / command prompt on your PC (for example, if you want to clone a project or write changes to the repository), you will probably be asked for the authenticity of the host you want to connect to. The fingerprints of the LRZ GitLab can be found on its instance configuration page.

Anchor
GitInvited
GitInvited

Can I collaborate with people on GitLab who do not have a LRZ/TUM/LMU User ID?

Yes, this is possible with GitInvited.

GitInvited was developed to give external cooperation partners access to GitLab. Each user who logs in to GitLab using an LDAP account (for example, LRZ, TUM, or LMU identifier) has a contingent of 20 invitations. These invitations can be sent to any email address via GitInvited. The email address must not be registered in GitLab prior to the invitation. 

User accounts created through this method have the status external user in LRZ GitLab. That means among other things, that they are not able to create their own projects or groups. See GitLab Permissions Dokumentation for details.

The user who sent the invitation (hereinafter referred to as the "Parent User") is linked to the invited user ("Child User") in the GitInvited database. This ensures that external users can be contacted by LRZ through their Parent Users.

If a Parent User is blocked in GitLab (for example because their ID has expired), all Child Users they are responsible for will also be blocked. This can only be prevented if those users are migrated to a new Parent User. This can only be done by the GitLab administrators. Please ask the new Parent User to contact the LRZ Servicedesk.

Although GitInvited and GitLab can be reached under different URLs, the services communicate with each other. When logging in for the first time, you will be redirected between the applications via the OAuth login procedure.

Anchor

Repo

Repository_verkleinern

Repo

Repository_verkleinern

How can I reduce the size of my repository?

If your project includes large or very dynamic files, the Git repository can get large. This not only affects the storage space and download times, but also causes additional load on our servers. Especially if you work with binary files and have forgotten to activate the Git Large File Storage (LFS), reducing the size of the repository is often necessary. The size of the project including the repository and LFS files is displayed on the project page. Rule of thumb: If the repository is larger than 1 GB without Git LFS, its size should be reduced.

Unfortunately, it is not enough to simply delete unnecessary files in the project directory. This doesn't make the repository smaller because the old versions of the files are still managed in Git.

Method 1: Recreating the project

The simplest and in most cases the recommended method is to recreate the project and to make sure that binary files are managed using Git LFS:

  1. Create a new, empty project (New Project → Blank project → <Fill in the project name and select "Initialize repository with a README">)
  2. Clone the new Projekt
    git clone https://gitlab.lrz.de/username/new-project-with-lfs.git
    (or via SSH: git clone git@gitlab.lrz.de:username/new-project-with-lfs.git)
  3. Copy files from the old project to the new project (without the .git/ directory)
  4. Initialize Git LFS and activate LFS tracking for binary files:
    git lfs install
    git lfs track '*.jpg'
    git lfs track '*.zip'
    git lfs track 'my_binary_data_file'
    ... additional lfs track commands for other files and data types if necessary ...

  5. Upload the files to GitLab
    git add .
    git commit -m "Initial commit"
    git push

  6. Delete the old project (Settings → General → Advanced → Remove project) 

This method will not preserve the version history of the files and associated, commit messages, branches and issues.

Method 2: Rewriting the version history

If the availability of the previous versions of the files, commit messages and/or branches of the project is important, this somewhat more complex method can be used. In this method the version history is partially rewritten with tools such as git-filter-repo or BFG Repo Cleaner. For example, source code files can be retained with their entire versioning while old versions of the large binary files are deleted. The details of how to use these tools depend on how the files are organized in the project. Below is an example of how the steps in this method may look like:

  1. Clone the existing project using the option "mirror"
    git clone --mirror https://gitlab.lrz.de/username/the-big-project.git
    (oder durch SSH: git clone --mirror git@gitlab.lrz.de:username/the-big-project.git)
  2. Delete selected files and folders using git-filter-repo. In our example the contents of the folder data as well as jpg- and zip-files will be removed from the project and its history. For details, please consult the documentation of the tools.
    cd the-big-project.git
    git-filter-repo --use-base-name --path-glob '*.jpg' --path-glob '*.zip' --invert-paths
    git-filter-repo --path data/ --invert-paths
  3. Upload the modified repository to a new project
    git push --mirror https://gitlab.lrz.de/username/new-project-with-lfs.git
    Clone the new project (without option "mirror"):
  4. cd ..
    git clone https://gitlab.lrz.de/username/new-project-with-lfs.git
    cd new-project-with-lfs
  5. Copy selected binary files and directories from the old project to the new project (without the .git / directory and the files that already exist in the new project repository).
  6. Initialize Git LFS and activate LFS tracking for binary files:
    git lfs install
    git lfs track '*.jpg'
    git lfs track '*.zip'
    git lfs track 'my_binary_data_file'
    ... additional lfs track commands for other files and data types if necessary ...
    Note: If you have multiple branches in your repository, please make sure that Git LFS is properly initialized in all branches.
  7. Upload the files to GitLab
    git add .
    git commit -m "Adds some data files"
    git push
  8. Delete the old project (Settings → General → Advanced → Remove project)

With this method, the versioning of files, branches and tags are retained. Branch requests on the GitLab web interface are lost, but because branches still exist, new branch requests can be easily created. Issues, comments, snippets and other content that is not part of the Git repository itself but is stored in the GitLab database are not retained.

Issues can be exported separately as CSV files and re-imported into the new project. However, comments in the issues are not retained.

Important: Also when using this method please make sure to create a new project with a new path and push the new size-reduced repository there. If you push it over the old project, the old versions of the files will still be retained as internal references on the server.

(For advanced users there is a method described on the GitLab page which rewrites the repository within the project and thus preserves all other data such as issues, comments, etc. as well as the original path. It's relatively complicated and we don't recommend it unless you are experienced with Git and GitLab. If you want to try this method, please ensure that all steps, including the repository cleanup with the commit.map file, are carried out. Furthermore it is important that all members of the project delete their local copies and re-clone the project. Otherwise their next git push will upload the old versions of the files, commits etc. back to the GitLab which will lead to a chaos.)