Skip to content
Snippets Groups Projects
Select Git revision
  • master default protected
  • work-in-progress
2 results
Blame Permalink
de_help.md 16.82 KiB 
layout: page
title: Hilfe
permalink: /hilfe/
ref: help
lang: de

Hier finden Sie erste Hilfe zur Benutzung von JLU GitLab, aber diese kann die offizielle Nutzerhilfe (auf Englisch){:target="_blank"} nicht ersetzen. Für spezifische Informationen zu JLU GitLab, siehe Informationen.

Inhalt {#toc}

Notwendige Begriffe {#essential_terms}

Git und GitLab sind vielschichtige Werkzeuge mit vielen technischen Konzepten und Begriffen. Da deren Entwicklung und Namensschöpfung auf Englisch stattfindet, sind diese bisher nur teilweise in andere Sprachen übersetzt worden. Um die weiteren Hilfestellungen (z.B. bezüglich Lese- und Schreibzugriff) kurz und verständlich zu halten, werden hier die wichtigsten Begriffe allgemeinverständlich erklärt. Dies ist nur eine gutgemeinte Übersicht; unter weitere Hilfe ist eine Sammlung von Links um sich mit diesen Konzepten vertraut zu machen.

Git-Begriffe {#terms_git}

  • Git{:target="_blank"} ist der Name einer Software für Versionskontrolle von Dateien.
  • Ein Repository ist eine Sammlung von Dateien, deren Bearbeitungsverlauf in Schnappschüssen versioniert wird. Mit Git kann man beliebig viele unterschiedliche Repositorien verwalten.
  • Ein Commit ist ein Schnappschuss der Daten im Repository. Beim Erstellen eines Commits werden die eingestellte Email-Adresse, der Name, das Datum, die Uhrzeit und ein beliebiges Kommentar untrennbar mit dem Datei-Inhalten der neuen Version verbunden. Dies ist eine grundlegende Sicherheitsvorkehrung von Git, um nachträgliche Änderungen dieses Schnappschusses zu verhindern. Lesen Sie hier, wie sie diese potentiell privaten Einstellungen ändern können.
  • Ein Branch ist ein benannter Teilverlauf von Schnappschüssen, um die Übersichtlichkeit eines Repository zu wahren.
  • Die Git-Kommandos pull und push können Branches von Git-Repositorien auf unterschiedlichen Geräten synchronisieren (wie etwa dem eigenen Computer und JLU GitLab). Sobald zwei Repositorien synchronisiert wurden, beinhalten beide eine Kopie aller Daten, d.h. den gesamten Verlauf von Schnappschüssen.

GitLab-Begriffe {#terms_gitlab}

  • Ein Projekt auf (JLU) GitLab enthält fast immer ein Git-Repository, und bietet viele zusätzliche Funktionen für dessen Verwaltung. Zusätzlich bietet GitLab mehrere Systeme um Quellcode eines Projekts automatisch auszuführen, z.B. um Tests auszuführen oder eine Webseite (wie diese) zu erstellen.
  • Jedes Projekt ist einem Namensraum eines Nutzungskontos oder Nutzergruppe zugeordnet. Alle Nutzenden haben jeweils ihren eigenen Namensraum für ihre persönlichen Projekte. Genauso haben alle Gruppen jeweils ihren eigenen Namensraum für Gruppenprojekte. Ihr Lese- und Schreibzugriff für ein Projekt hängen indirekt von dessen Namensraum ab: In Projekten im Namensram von anderen Nutzenden richten Sich Ihre Berechtigungen nach der Sichtbarkeit des Projekts, und falls Sie Projektmitglied sind, Ihrer Nutzerrolle im Projekt. In Gruppenprojekten richten sich die Berechtigungen außerdem nach der Sichtbarkeit der Gruppe, und für Gruppenmitglieder sind nach deren Nutzerrolle in der Gruppe.

Wie benutzt man GitLab? {#how_to_gitlab}

TODO: Viele Kleinigkeiten mit Browser möglich, für umfangreichere Arbeit aber Git lokal installieren.

TODO: Hinweis auf Git-GUIs (vielleicht mit Empfehlung)?

TODO: Hinweis auf Git-Funktionen in Matlab und anderen IDEs?

Erste Schritte {#first_steps}

TODO: Grobe Übersicht, links auf gute Ressourcen zum Weiterlernen (siehe unten).

TODO: Wie man die Sprache einstellt.

TODO: Link zur Führung in GitLab (oder gibt es die nur in EE?).

Sichtbarkeit von Projekten {#project_visibility}

Jedes Projekt hat eine Sichtbarkeits-Einstellung als entweder private, internal oder public. Die Sichtbarkeit kann nur von Nutzenden mit der Owner-Rolle im Projekt geändert werden (siehe Nutzerrollen in Projekten und in Gruppen).

  • Projekte mit Sichtbarkeit private sind nur für die Mitglieder des Projekts einsehbar.
  • Projekte mit Sichtbarkeit internal sind für alle Personen mit einem Nutzungskonto einsehbar, die eingeloggt sind.
  • Projekte mit Sichtbarkeit public sind auch für alle Personen einsehbar, die kein Nutzungskonto haben.

Bitte lesen Sie hier, was die Sichtbarkeitsstufen internal und public im Fall von JLU GitLab bedeuten. Für mehr Details lesen Sie bitte die offizielle Dokumentation (auf Englisch){:target="_blank"}.

Nutzerrollen in Projekten {#project_roles}

Beim Hinzufügen von Projektmitgliedern müssen Sie ihnen bestimmte Rollen zuweisen: Sie können zwischen Guest, Reporter, Developer, Maintainer oder Owner auswählen. Jede dieser Rollen umfasst mehr Berechtigungen als die vorherige, siehe auch in der offiziellen Dokumentation (auf Englisch){:target="_blank"}. Für Projekte im Namensraum einer Gruppe haben die Gruppenmitglieder ihre gleichnamigen Gruppenrolle inne; z.B. ist ein Guest in der Gruppe auch ein Guest in allen Gruppenprojekten, sofern dies nicht durch individuelle Projektrollen überschrieben ist.

Berechtigungen als Guest {#project_guest}

Die Guest-Rolle ist für nicht-aktive Mitglieder, die einige Inhalte lesen, und Tickets öffnen und kommentieren können.

Projektmitglieder in der Guest-Rolle können das Projekt herunterladen, Kommentare einbringen, Projektdateien ansehen und Git-pullen, Wikiseiten ansehen, neue Tickets erstellen, verwandte Tickets ansehen, vertrauliche Tickets erstellen, und selbsterstellte vertrauliche Tickets ansehen. Wenn Öffentliche Pipelines in den Projekteinstellungen > CI/CD aktiviert ist, können sie zusätzlich eine Liste der Jobs anschauen, ein Job-Protokoll ansehen, und Job-Artefakte durchsehen und herunterladen.

Berechtigungen als Reporter {#project_reporter}

Die Reporter-Rolle ist für Mitglieder die mehr Einblick bekommen und im Ticketsystem walten können. Projektmitglieder mit der Reporter-Rolle habe folgende zusätzliche Berechtigungen im Vergleich zur Guest-Rolle:

Im Ticketsystem können Reporter Tickets zuweisen und mit Labels versehen, Kommentare sperren, und die Ticketliste und Labels verwalten. Reporter können außerdem Codeausschnitte speichern, den Status eines Commits einsehen, die Container Registry ansehen, Umgebungen ansehen, eine Liste von Merge-Requests ansehen, Projekt-Statistiken ansehen, und die Error-Tracking-Liste ansehen.

Berechtigungen als Developer {#project_developer}

Die Developer-Rolle ist für Projektmitglieder die aktiv beitragen, und allen nötigen Zugriff haben um eine Idee umzusetzen, solange etwas nicht explizit beschränkt wurde (z.B. durch Branch-Protection). Projektmitglieder mit der Developer-Rolle haben die folgenden zusätzlichen Berechtigungen im Vergleich zur Reporter-Rolle:

Im Git-Repository können Developer neue Branches anlegen, und auf nicht-schreibgeschützte Branches pushen, oder diese löschen. Sie können neue Merge-Requests anlegen, bestehende verwalten/akzeptieren, sie anderen zuweisen und mit Labels versehen, und deren Kommentarverlauf sperren. Sie können neue Umgebungen anlegen und diese stoppen. Zusätzlich können Developer Jobs abbrechen und neustarten, und den Commit-Status anlegen oder aktualisieren. Sie können die Container-Registry aktualisieren, oder ein Image in der Container-Registry löschen. Im Ticketsystem können sie Meilensteine anlegen, bearbeiten, und löschen, und Label hinzufügen. Sie können Änderungsvorschläge annehmen, Wikiseiten anlegen und bearbeiten, und Git-Tags überschreiben/löschen.

Berechtigungen als Maintainer {#project_maintainer}

Die Rolle Maintainer ist für Mitglieder die ein Projekt und dessen Mitglieder verwalten. Projektmitglieder in der Maintainer-Rolle bekommen die folgenden zusätzlichen Berechtigungen im Vergliech zur Developer-Rolle:

Maintainer können neue Projektmitglieder hinzufügen, Umgebungs-Terminals verwenden, Branch-Schreibschutz ein/ausschalten, auf schreibgeschützte Branches pushen, den Schreibschutz für push durch Developer an/ausschalten, Schreibschutz von Tags an/ausschalten. Maintainer können die Projekteinstellungen bearbeiten, Deploy-Schlüssel zu dem Projekt hinzufügen, und Projekt-Hooks konfigurieren. Sie können Runners verwalten, Job-Trigger verwalten, und Umgebungs-Variablen verwalten. Falls GitLab Pages aktiviert ist, können sie diese verwalten und löschen, und deren Domains und Zertifikate verwalten. Sie können Cluster verwalten, Kommentare von beliebigen Nutzenden bearbeiten, das Error Tracking verwalten, und Wikiseiten löschen.

Berechtigungen als Owner {#project_owner}

Nutzende in der Owner-Rolle kontrollieren alle Aspekte eines Projekts, inklusive dessen Löschung. In persönlichen Projekten (im Namensraum eines Nutzungskontos) hat ausschließlich diese Person die Owner-Rolle. In Gruppenprojekten (im Namensraum einer Gruppe) kann es mehrere Owner geben, sofern mehrere Gruppenmitglieder die Gruppenrolle Owner innehaben. Projektmitglieder in der Owner-Rolle haben die folgenden zusätzlichen Berechtigungen im Vergleich zur Maintainer-Rolle:

Owner können die Sichtbarkeitsstufe des Projekts ändern, das Projekt in einen anderen Namensraum transferieren, das Projekt löschen, Tickets löschen, und Benachrichtigungs-Emails ausschalten.

Beachten Sie, dass nach der Benutzungsordnung von JLU GitLab alle Nutzenden mit der Owner-Rolle für den Inhalt ihrer Projekte verantwortlich sind, auch wenn diese von anderen Nutzenden stammen.

Nutzergruppen {#group}

Alle Nutzenden könnten Gruppen anlegen um mehrere Projekte und Personen zu organisieren. Beachten Sie, dass Daten die Sie zu Gruppenprojekten beitragen nicht gelöscht werden wenn Sie die Universität verlassen oder ihr Nutzungskonto löschen, solange die Gruppe mindestens ein Mitglied enthält.

Die Zugriffsrechte eines Projekts im Namensraum einer Gruppe hängt von der Sichtbarkeit und den Rollen der Gruppe ab. Außerdem können individuelle Nutzende auch von außerhalb der Gruppe als Projektmitglied zu individuellen Gruppenprojekten hinzugefügt werden.

Sichtbarkeit von Gruppen {#group_visibility}

Wie die Sichtbarkeit von Projekten kann die Sichtbarkeit von Gruppen auf 1) private, 2) internal oder 3) public gesetzt werden, um den Zugriff entweder 1) nur explizit ausgewählten Mitgliedern zu gewähren, oder 2) allen eingeloggten Nutzenden, oder 3) allen Personen, inklusive solchen ohne Nutzungskonto. Bitte lesen Sie hier, was die Sichtbarkeitsstufen internal und public im Fall von JLU GitLab bedeuten.

Nutzerrollen in Gruppen {#group_roles}

Wenn Sie Nutzende als Gruppenmitglieder hinzugefügen, müssen Sie ihnen auch eine Gruppenrolle zuordnen: Wie die Nutzerrollen in Projekten können Sie wählen zwischen Guest, Reporter, Developer, Maintainer oder Owner. Die Gruppenrolle eines Mitglieds setzt die Berechtigungen der gleichnamigen Projekt-Rolle für alle Gruppenprojekte. Zusätzlich kann die Projekt-Rolle eines Mitglieds individuell pro Projekt angepasst werden.

Jede Gruppenrolle kommt mit zusätzlichen Berechtigungen innerhalb der Gruppe selbst, siehe auch in der offiziellen Dokumentation (auf Englisch){:target="_blank"}:

Guests können eine Gruppe nur einsehen, nichts verändern.

Reporter können zusätzlich die Gruppen-Label verwalten.

Developer können zusätzlich Projekte in der Gruppe anlegen, und können Meilensteine der Gruppe anlegen/ändern/löschen.

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.

Beachten Sie, dass nach der Benutzungsordnung von JLU GitLab alle Nutzenden mit der Owner-Rolle für den Inhalt ihrer Projekte verantwortlich sind, auch wenn diese von anderen Nutzenden stammen.

Einstellungen, die private Informationen betreffen {#settings_privacy}

TODO: Beschreibung der Einstellungen von Commit-Namen und -Emailadresse (in GitLab und lokal), Profil und Aktivitäten unsichtbar machen, ...

Letzte Schritte {#last_steps}

Bevor Sie die Universität verlassen oder Ihr Nutzungskonto löschen, können Sie einige Optionen bedenken um ihre Projekte zu behalten, oder sie anderen Nutzenden zu übertragen, denn beim Löschen eines Kontos werden auch alle persönlichen Projekte mitgelöscht.

Bespielsweise werden Sie alle wichtigen Git-Repositorien von JLU GitLab auf Ihren Computer synchronisieren wollen, um Datenverluste zu verhindern.

Um das Löschen eines persönlichen Projekts im eigenen Namensraum zu verhindern, können Sie es in den Namensraum einer anderen Person oder Gruppe transferieren. Dies muss mit den neuen Eigentümern mit Owner-Rolle koordiniert werden.

Sie können Projekte außerdem exportieren; dies erlaubt Ihnen, (nahezu) alle zugehörigen Daten auf eine andere GitLab-Instanz zu übersiedeln. Im Unterschied zum bloßen Synchronisieren der Git-Repositorien schließt dies auch die Ticketsystem, Wiki, usw. mit ein.

Wie kann ich mein Nutzungskonto löschen? {#deletion_account}

Sie können Ihr Nutzungskonto jederzeit löschen, indem Sie Einstellungen > Konto > Konto löschen in ihrem Browser öffnen und mit ihrem Passwort bestätigen.

Bevor Sie Ihr Konto löschen, lesen Sie bitte diese Übersicht welche Daten mitgelöscht werden; mit ein paar letzten Schritten könnten Sie mögliche Ärgernisse umgehen.

Beachten Sie, dass Sie ihr Konto nicht sofort löschen können, falls Sie die einzige Person mit Owner-Rolle in einer Gruppe sind. In diesem Fall müssen Sie mindestens ein anderes Mitglied als Owner einstellen, oder die betreffende Gruppe löschen (z.B. falls Sie das einzige Mitglied sind).

Weitere Hilfe {#more_help}

TODO: Mehr nützliche Links, evtl. in Kategorien; GitLab selbst hat noch eine Menge.