Page tree
Skip to end of metadata
Go to start of metadata
Deutsch  English

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.

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.

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.)

  • No labels