---
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)](https://gitlab.test.uni-giessen.de/help/user/index.md){:target="_blank"} nicht ersetzen.
Für spezifische Informationen zu JLU GitLab, siehe [Informationen]({{ '/informationen/#what_is_jlugitlab' | relative_url }}).

## Inhalt {#toc}

<!-- NOTE dies ist (derzeit) nur eine manuell verwaltete Liste. -->
- [Nötige Begriffe](#necessary_terms)
- [Wie benutzt man GitLab?](#how_to_gitlab)
- [Erste Schritte](#first_steps)
- [Sichtbarkeit von Projekten](#visibility_projects)
- [Nutzerrollen in Projekten](#user_roles)
    - [Berechtigungen als *Guest*](#role_guest)
    - [Berechtigungen als *Reporter*](#role_reporter)
    - [Berechtigungen als *Developer*](#role_developer)
    - [Berechtigungen als *Maintainer*](#role_maintainer)
    - [Berechtigungen als *Owner*](#role_owner)
- [Nutzergruppen](#groups)
- [Einstellung von privater Informationen](#private_info)
- [Letzte Schritte](#last_steps)
- [Weitere Hilfe](#more_help)

## Nötige Begriffe {#necessary_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](#more_help) ist eine Sammlung von Links um sich mit diesen Konzepten vertraut zu machen.

### Git Terminologie {#necessary_terms_git}

- Ein Git *Repository* bezeichnet eine Sammlung von Dateien und Ordnern, deren Bearbeitungsverlauf in Schnappschüssen gespeichert wird.
  Man kann beliebig viele unterschiedliche Repositories verwalten.
- Ein *Commit* ist ein bestimmter Schnappschuss der Daten im Repository.
  Beim Erstellen eines Commits werden der eingestellte Name, die Email-Adresse, das Datum, die Uhrzeit und ein beliebiges Kommentar untrennbar mit den Daten der neuen Version verbunden.
  Dies ist eine grundlegende Sicherheitsvorkehrung von Git, um nachträgliche Änderungen dieser Version zu verhindern.
  Lesen Sie [hier](#private_info), wie sie diese privaten Einstellungen ändern können.
- Ein *Branch* ("Zweig") ist ein bestimmter Teilverlauf von Schnappschüssen, d.g. ein Teil eines Git-Repositories.
- Mit den Git-Kommandos *pull* und *push* wird ein Branch eines Git-Repository zwischen 2 Orten synchronisiert (z.B. zwischen dem eigenen Computer und JLU GitLab).

### GitLab Terminologie {#necessary_terms_gitlab}

- Ein Projekt auf (JLU) GitLab enthält ein Git-Repository, und bietet viele zusätzliche Funktionen für dessen Verwaltung.
- Jedes Projekt sind einem *Namensraum* zugeordnet.
  Alle Nutzenden und alle Nutzergruppen haben einen eigenen Namensraum, in dem sie Projekte speichern können.
  Der Lese- und Schreibzugriff hängt ab von der [Sichtbarkeit des Projekts](#visibility_projects) und der eigenen [Rolle als Projektmitglied](#user_roles) bzw. den Sichtbarkeits- und Rolleneinstellungen der betreffenden [Nutzergruppe](#groups).
- Mit einem *Merge-Request* kann man beantragen, einen oder mehrere Commits von einem Git-Repository in ein anderes Repository zu übernehmen.

## 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 (ohne 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](#more_help)).

## Sichtbarkeit von Projekten {#visibility_projects}

Jedes Projekt hat eine Sichtbarkeits-Einstellung als entweder *private*, *internal* oder *public*.
Die Sichtbarkeit kann nur vom *Owner* des Projekts geändert werden (siehe [Nutzerrollen unten](#user_roles)).

- Projekte mit Sichtbarkeit *private* sind nur für die [Mitglieder des Projekts](#user_roles) einsehbar.
- Projekte mit Sichtbarkeit *internal* sind für alle Personen mit einem Nutzungskonto einsehbar, die eingeloggt sind.
  [Bitte lesen Sie hier, was dies im Fall von JLU GitLab bedeutet.]({{ '/informationen/#potential_users' | relative_url }})
- Projekte mit Sichtbarkeit *public* sind auch für alle Personen einsehbar, die kein Nutzungskonto haben.
  [Bitte lesen Sie hier, was dies im Fall von JLU GitLab bedeutet.]({{ '/informationen/#potential_users' | relative_url }})

Für mehr Details lesen Sie bitte die [offizielle Dokumentation (auf Englisch)](https://gitlab.test.uni-giessen.de/help/public_access/public_access.md#public-access){:target="_blank"}.

## Nutzerrollen in Projekten {#user_roles}

TODO: Fehlende Bedeutungen von *Reporter* bis *Owner*.

Wenn Sie andere Nutzende als Projektmitglied hinzufügen wollen, müssen Sie diesen auch eine bestimmte Rolle 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)](https://gitlab.test.uni-giessen.de/help/user/permissions.md#project-members-permissions){:target="_blank"}.
<!-- NOTE: Der Einfachheit halber, lass uns unten die Berechtigungen von den Verträgen STARTER, PREMIUM, ULTIMATE weglassen; unter der Annahme dass diese nicht Teil der Community Edition sind. -->

### Berechtigungen als *Guest* {#role_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-*pull*en,
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* {#role_reporter}

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

Im Ticketsystem können sie 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,
eine Container Registry ansehen,
Umgebungen ansehen,
eine Liste von Merge-Requests ansehen,
Projekt-Statistiken ansehen,
und die Error-Tracking-Liste ansehen.
<!-- NOTE: Error Tracking (keine dt. Übersetzung) ist unter Vorgängen zu finden, man muss mit mit einem Sentry-Server verbinden. -->

### Berechtigungen als *Developer* {#role_developer}

Die *Developer*-Rolle ist für Projektmitglieder die direkt mitarbeiten, 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 sie neue Branches anlegen,
und auf nicht-geschützte Branches *push*en, oder diese löschen.
Regarding merge requests, they can create new ones,
manage/accept,
assign and label existing ones,
and lock merge request threads.
They can create new environments and stop them.
*Developers* can cancel and retry jobs,
create or update commit status.
They can update a container registry, or
remove a container registry image.
In the issue tracker, they can create/edit/delete project milestones, and add tags.
They can apply code change suggestions,
create and edit wiki pages, and
Git-Tags überschreiben/löschen.

### Berechtigungen als *Maintainer* {#role_maintainer}

TODO

### Berechtigungen als *Owner* {#role_owner}

TODO

## Nutzergruppen {#groups}

TODO: Gruppenmitglieder und deren Rollen und einhergehende Rechte.

TODO: Hinweis, dass Projekte in Gruppen nicht beim Austritt gelöscht werden, sofern noch andere Nutzende in der Gruppe sind.

[Ähnlich zur Sichtbarkeit von Projekten](#visibility_projects) kann die Sichtbarkeit von Gruppen auf *private*, *internal* oder *public* gesetzt werden, um den Zugriff entweder nur explizit ausgewählten Mitgliedern zu gewähren oder allen eingeloggten Nutzenden oder sogar allen Personen ohne Nutzungskonto.

## Einstellung von privater Informationen {#private_info}

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

## Letzte Schritte {#last_steps}

TODO: Erklärung, was wann bei Austritt aus der JLU gelöscht wird (Nutzerdaten, *eigene* Projekte, ...), und was nicht (Projekte in Gruppen inkl Tickets und Kommentare, Commits, ...).

Außer den Commits werden Daten anonymisiert (auf den Ghost-User übertragen).

## Weitere Hilfe {#more_help}

TODO: Mehr nützliche Links, evtl. in Kategorien.

- Die offizielle Nutzerhilfe für JLU GitLab (auf Englisch), <https://gitlab.test.uni-giessen.de/help/user/index.md>
- Kostenloses Online-Buch *Pro Git*, <https://git-scm.com/book/de>, teilweise auf Deutsch übersetzt