Newer
Older
Hier finden Sie erste Hilfe zur Benutzung von JLU GitLab, aber diese kann [die offizielle Nutzerhilfe (auf Englisch)](https://gitlab.ub.uni-giessen.de/help/user/index.md) nicht ersetzen.
Für spezifische Informationen zu JLU GitLab, siehe [Informationen](Informationen.md).
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](#weitere-hilfe) ist eine Sammlung von Links um sich mit diesen Konzepten vertraut zu machen.
- [*Git*](https://de.wikipedia.org/wiki/Git) 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](#einstellungen-die-private-informationen-betreffen), wie sie diese potentiell privaten Einstellungen ändern können.
- Ein *Branch* ist ein benannter Verlauf von Schnappschüssen, um die Übersichtlichkeit eines Repository zu wahren.
- Die Git-Befehle `pull` und `push` können Branches von Git-Repositorien auf unterschiedlichen Geräten synchronisieren (wie etwa dem eigenen Computer und JLU GitLab).
Sobald zwei Branches synchronisiert wurden, beinhalten beide eine Kopie aller Daten, d.h. den gesamten Verlauf von Schnappschüssen.
- 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](#sichtbarkeit-von-projekten), und falls Sie Projektmitglied sind, Ihrer [Nutzerrolle im Projekt](#nutzerrollen-in-projekten).
In Gruppenprojekten richten sich die Berechtigungen außerdem nach der [Sichtbarkeit der Gruppe](#sichtbarkeit-von-gruppen), und für Gruppenmitglieder sind nach deren [Nutzerrolle in der Gruppe](#nutzerrollen-in-gruppen).
<!--NOTE, nicht nötig?: - Mit einem *Merge-Request* kann man anfragen, einen oder mehrere Commits von einem Git-Repository in ein anderes zu übernehmen. -->
## Wie benutzt man GitLab?
Es gibt zwei Hauptwege, die verschiedenen Funktionen von GitLab zu nutzen.
Besonders komfortabel ist die Arbeit per Web-Browser: Sie können beispielsweise Inhalte lesen, Tickets kommentieren, Wikiseiten editieren, und per [Web Editor](https://docs.gitlab.com/ee/user/project/repository/web_editor.html) oder [Web IDE](https://docs.gitlab.com/ee/user/project/web_ide/) auch Dateien im Git Repository editieren.
Für umfangreichere Änderungen empfiehlt sich die Arbeit an einer lokalen Kopie eines Git Repository.
Hierzu benötigen Sie Git auf Ihrem Computer, um ihre lokale Kopie mit der auf GitLab synchron zu halten (mit Git `pull` und `push`).
Gängige Programmier-Software (wie Matlab oder RStudio) unterstützt meist die Arbeit mit einem lokalen Git Repository.
Zum Synchronisieren ihrer Änderungen mit JLU GitLab müssen Sie sich [verbinden](#wie-verbindet-man-sich-mit-jlu-gitlab) und [authentifizieren](#wie-authentifiziert-man-sich-bei-jlu-gitlab).
## Wie verbindet man sich mit JLU GitLab?
JLU GitLab ist über zwei Netzwerkprotokolle erreichbar: Per `HTTPS` oder per `SSH`.
Jede Anwendung (wie Webbrowser, Git, usw.) muss eines dieser Protokolle benutzen.
Verbindungen per HTTPS sind empfohlen und direkt aus dem Internet möglich.
HTTPS bietet Zugriff auf alle Funktionen von GitLab (Git-über-HTTP und GitLab APIs).
Authentifizierung ist möglich per [HRZ-Zugangsdaten](#authentifizierung-mit-hrz-zugangsdaten) (unsicher und unflexibel) oder per [Access Token](#authentifizierung-mit-access-token) (sicher und flexibel).
Verbindungen per SSH sind nur [per VPN](https://www.uni-giessen.de/fbz/svc/hrz/svc/netz/campus/vpn) möglich.
SSH bietet nur die Synchronisation von Git Repositories, keine weiteren GitLab Funktionen.
Zur Authentifizierung benötigen Sie [einen SSH-Schlüssel](#authentifizierung-mit ssh-schluessel).
Beachten Sie, beim *Clone*n eines Git Repository die URL mit der gewünschten Verbindungsart auszuwählen:
## Wie authentifiziert man sich bei JLU GitLab?
Um Zugriff auf ihr Nutzungskonto oder ihre Projekte zu erhalten, müssen Sie sich bei JLU GitLab [authentifizieren](https://de.wikipedia.org/wiki/Authentifizierung).
Zum [Erstellen Ihres Nutzungskontos](#wie-erstelle-ich-ein-nutzungskonto) müssen Sie sich einmal per Browser mit ihrer HRZ-Kennung und -Passwort anmelden.
Sobald Sie ein Nutzungskonto haben, gibt es verschiedene Authentifizierungsmethoden unter denen Sie wählen können.
Hier sind 3 Methoden der Authentifizierung gegenübergestellt, um eine Abwägung zwischen Sicherheit und Benutzbarkeit zu erleichtern.
Vorab: Die empfohlene Methode ist die [Authentifizierung mit einem (persönlichem) Access Token](#authentifizierung-mit-access-token), sobald Ihnen die Funktionen im Browser nicht mehr ausreichen.
- Per [HRZ-Kennung und -Passwort](#authentifizierung-mit-hrz-zugangsdaten).
- Per [(persönlichem) Access Token](#authentifizierung-mit-access-token).
- Per [SSH-Schlüssel](#authentifizierung-mit-ssh-schlüssel).
Hier eine Übersicht der wichtigsten Vor- und Nachteile; die Erläuterungen finden Sie weiter unten.
| Methode | Empfohlen | Nutzbar mit 2FA | Nutzbar ohne VPN | Flexible Verwaltung |
|-----------------------|---------------|-----------------|------------------|---------------------|
| HRZ-Kennung | Nein | Nein | Ja | Nein |
| Personal Access Token | Ja | Ja | Ja | Ja |
| SSH-Schlüssel | Eingeschränkt | Nein | Nein | Eingeschränkt |
### Authentifizierung mit HRZ-Zugangsdaten
Bei [Verbindung per HTTPS](#wie-verbindet-man-sich-mit-jlu-gitlab) (z.B. per Webbrowser oder Git) können Sie sich mit ihrer persönlichen HRZ-Kennung und HRZ-Passwort authentifizieren.
Einziger __Vorteil__ dieser Methode ist ihre Einfachheit.
Wichtiger __Nachteil__ dieser Methode ist ihr Schadenspotential:
In JLU GitLab sind ihre HRZ-Zugangsdaten *immer* mit *allen* ihren Berechtigungen verbunden, inklusive dem Löschen ihrer Daten und ihres Nutzungskontos.
Dies kann bei eigenen Bedienfehlern oder Passwort-Diebstahl zum größtmöglichen Schaden führen.
Auch außerhalb von JLU GitLab sind ihre HRZ-Zugangsdaten besonders schützenswert, da sie als "Generalschlüssel" für viele IT-Systeme der JLU verwendet werden (z.B. Emailzugriff).
Bei Verlust ihres HRZ-Passworts haben Sie selbst (vorübergehend) keinen Zugriff mehr.
Für flexibel eingeschränkte Zugriffsberechtigungen, insbesondere für (automatische) Zugriffe von mehreren Geräten, empfiehlt sich die [Verwendung von Access Tokens](#authentifizierung-mit-access-token) anstelle ihrer HRZ-Zugangsdaten.
Für höhere Sicherheit bei Diebstahl ihres HRZ-Passworts können Sie in JLU GitLab [2-Faktor-Authentisierung (2FA)](https://docs.gitlab.com/ee/user/profile/account/two_factor_authentication.html) aktivieren.
Beachten Sie, dass Sie bei aktivierter 2FA für [Git-über-HTTPS](#wie-verbindet-man-sich-mit-jlu-gitlab) ein [persönliches Access Token](#authentifizierung-mit-access-token) erstellen und nutzen müssen.
### Authentifizierung mit Access Token
Ein *Access Token* ist eine von JLU GitLab zufällig erzeugte Zeichenkette mit bestimmten Berechtigungen, die Sie anstelle ihrer HRZ-Zugangsdaten benutzen können.
Die Verwendung von Access Tokens erfordert eine [Verbindung per HTTPS](#wie-verbindet-man-sich-mit-jlu-gitlab).
__Vorteile__ dieser Methode sind die Trennung ihrer sensitiven HRZ-Zugangsdaten und die Flexibilität der Berechtigungen nach Einsatzzweck.
Dies kann den Schaden im Fall von Diebstahl, Verlust, oder Bedienfehlern begrenzen.
__Nachteile__ sind die erforderliche Einrichtung und Gewöhnung an den Umgang, die mit den folgenden Hilfetexten zur [Erstellung](#erstellen-eines-persönlichen-access-tokens) und [sicheren Speicherung und Verwendung](#sicheres-speichern-und-verwenden-eines-access-tokens) von (persönlichen) Access Tokens vereinfacht werden sollen.
Ein [persönliches](https://docs.gitlab.com/ee/user/profile/personal_access_tokens.html) Access Token (PAT) erlaubt Berechtigungen auf alle Bereiche ihres Nutzungskontos (Git-über-HTTPS und API).
Falls Sie für höhere Sicherheit [2-Faktor-Authentisierung](https://docs.gitlab.com/ee/user/profile/account/two_factor_authentication.html) nutzen wollen, müssen Sie für Authentifizierung über HTTPS ein PAT erstellen und nutzen (siehe unten).
Neben *persönlichen* Access Tokens gibt es auch solche für [Projekte](https://docs.gitlab.com/ee/user/project/settings/project_access_tokens.html) und [Nutzergruppen](https://docs.gitlab.com/ee/user/group/settings/group_access_tokens.html).
Sie werden analog zu einem persönlichen Token benutzt, aber erlauben eine zusätzliche Berechtigungsbeschränkung auf einzelne Projekte, bzw. Gruppen.
#### Erstellen eines persönlichen Access Tokens
Um ein persönliches Access Token (PAT) erstellen zu können, melden Sie sich per Browser an, klicken Sie rechts oben auf ihr Profil, wählen Sie *Edit profile* und anschließend *Access Tokens* im linken Seitenmenü.
Alternativ können Sie auf auf [diesen Direktlink](https://gitlab.ub.uni-giessen.de/-/profile/personal_access_tokens) klicken.
Beachten Sie, dass Sie mehrere PATs für unterschiedliche Einsatzzwecke erstellen können; beispielsweise eins für ihr Laptop und ein anderes mit weniger Berechtigungen und früherem Ablaufdatum für einen Laborrechner.
Um ein PAT zu erstellen:
1. Wählen Sie unter __Token name__ eine passende Bezeichnung für das Token, beispielsweise den Namen des Gerätes, für das das Token bestimmt ist.
2. Vergeben Sie nach Möglichkeit unter __Expiry date__ ein Verfallsdatum der Gültigkeit des Tokens.
Diese Abwägung hängt vom Einsatzzweck ab.
3. Erlauben Sie die benötigten Berechtigungen für den Einsatzzweck des Tokens;
beispielsweise genügt __write\_repository__ für den Lese- und Schreibzugriff auf alle ihre Git Repositories.
Eine Übersicht möglicher Berechtigungen finden sie [hier](https://gitlab.ub.uni-giessen.de/help/user/profile/personal_access_tokens.md#personal-access-token-scopes).
4. Klicken Sie *Create personal access token*:
Nun wird die eindeutige, zufällige Zeichenkette des neuen Tokens angezeigt, beispielsweise `aztGzZkCT-kGyRs1M6x1`.
Da die Zeichenkette nur direkt nach dem Erstellen angezeigt wird, sollten Sie sie sofort [zur Verwendung sicher speichern (siehe unten)](#sicheres-speichern-und-verwenden-eines-access-tokens).
#### Sicheres Speichern und Verwenden eines Access Tokens
Um ein Access Token zu nutzen, muss es für jede Verbindung mit GitLab vorliegen.
Anstatt es wiederholt einzutippen oder ungesichert zu speichern, empfiehlt sich die folgende sichere Methode, das Token verschlüsselt abzuspeichern.
<!--
Achtung: Auch unsicheres Speichern ist möglich; vergewissern Sie sich, dass ihre Git-Konfiguration ihren Sicherheitsansprüchen genügt.
Durch die eingesetzte Verschlüsselung ist diese Methode nur für interaktives Arbeiten nützlich.
(Und da automatisierter Zugriff ohnehin weiteres Wissen und Abwägung erfordert, wird hier nicht weiter darauf eingegangen.)
-->
##### Vorraussetzung: Verschlüsselter Speicher für Git-Anmeldeinformationen
Aktuelle Git-Versionen unterstützen das verschlüsselte Abspeichern Ihrer Anmeldeinformationen.
Je nach Betriebssystem wird die Verschlüsselung von unterschiedlichen Hilfsprogrammen realisiert.
Bei Installation des aktuellen, [offiziellen Git Clients](https://git-scm.com/) unter _Windows_ oder _macOS_ werden sichere Standardeinstellungen gesetzt, die den systemeigenen verschlüsselten Speicher nutzen.
Hierzu ist von Ihnen keine Konfiguration nötig.
Das konfigurierte Hilfsprogramm können Sie über `git config credential.helper` einsehen und verändern; die sichere Standardeinstellung für Windows ist `manager-core`, für macOS `osxkeychain`.
Für _Linux_, oder falls Sie _Multifaktor-Authentisierung_ nutzen möchten, empfiehlt sich das Hilfsprogramm [*Git Credential Manager (GCM)*](https://github.com/GitCredentialManager/git-credential-manager#git-credential-manager).
Unter Linux müssen Sie sich nach [Installation und Konfiguration von *GCM*](https://github.com/GitCredentialManager/git-credential-manager#linux) außerdem für einen [*Credential Store* entscheiden](https://github.com/GitCredentialManager/git-credential-manager/blob/main/docs/credstores.md#credential-stores), beispielsweise für *SecretService*, per `git config --global credential.credentialStore secretservice`.
##### Token sicher speichern und verwenden
Wenn die [Vorraussetzungen zum sicheren Speichern](##vorraussetzung-verschlüsselter-speicher-für-git-anmeldeinformationen) erfüllt sind und Sie ein [Token erstellt](#erstellen-eines-persönlichen-access-tokens) haben bleiben nur zwei Schritte zur Nutzung des Tokens:
1. Starten Sie von ihrem Gerät eine beliebige Git-Aktion, die eine Authentifizierung bei GitLab über HTTPS erfordert; beispielsweise Lesezugriff auf ein privates Projekt per `git pull` oder `git clone`.
Achten Sie dabei darauf eine HTTPS-URL zu nutzen, die mit `https://` startet (prüfen Sie im Zweifel die eingestellte Git-Remote URL).
2. Tragen Sie bei Aufforderung ihrer Zugangsdaten ihr neues Token *anstelle ihres Passworts* ein:
- Als Nutzername wählen Sie ihre HRZ-Kennung.
- Als Passwort nutzen Sie die Token-Zeichenkette, die Sie beim [Erstellen](#erstellen-eines-persönlichen-access-tokens) erhalten, beispielsweise `aztGzZkCT-kGyRs1M6x1`.
Hier ein Screenshot des erwarteten Dialogfensters von Windows 10:
### Authentifizierung mit SSH-Schlüssel
Beachten Sie, dass Zugriff per SSH nur [per VPN](https://www.uni-giessen.de/fbz/svc/hrz/svc/netz/campus/vpn) möglich ist.
Die __Vor- und Nachteile__ dieser Methode befinden sich zwischen der unsicheren und unflexiblen Nutzung ihrer HRZ-Zugangsdaten und der noch sichereren und flexibleren [Authentifizierung per Access Token](#authentifizierung-mit-access-token).
Zur Erstellung eines SSH-Schlüsselpaars gibt es eine [deutschsprachige Anleitung im Buch *Pro Git*, Kapitel 4.3](https://git-scm.com/book/de/v2/Git-auf-dem-Server-Erstellung-eines-SSH-Public-Keys).
Anschließend müssen Sie den öffentlichen(!) Schlüssel bei ihrem JLU GitLab-Konto hinterlegen.
Lesen Sie dazu z.B. diese [englischsprachige Dokumentation](https://gitlab.ub.uni-giessen.de/help/ssh/index.md#add-an-ssh-key-to-your-gitlab-account).
## Wie erstelle ich ein Nutzungskonto?
Zum Anlegen eines JLU GitLab Nutzungskontos wird eine vorhandene JLU Benutzerkennung (g-, s-, n-, oder j-) benötigt.
Informationen zu JLU Benutzerkennungen [finden Sie hier](https://www.uni-giessen.de/fbz/svc/hrz/svc/ident/account?set_language=de).
Mit vorhandener JLU Benutzerkennung wird Ihr Nutzungskonto bei der ersten Anmeldung angelegt, sofern Sie die [Nutzungsbedingungen](Nutzungsbedingungen.md) akzeptieren.
Gehen Sie zur Anmeldung auf https://gitlab.ub.uni-giessen.de/ und geben Sie ihre [JLU Benutzerkennung](https://www.uni-giessen.de/fbz/svc/hrz/svc/ident?set_language=de) (g-, s-, n-, oder j-Kennung) in das Feld **JLU (g-/s-/n-/j-) Username** und ihr zugehöriges, persönliches Passwort in das Feld **Password** ein.
Nach ihrer ersten Anmeldung werden Ihnen die [Nutzungsbedingungen](Nutzungsbedingungen.md) gezeigt; ihr Nutzungskonto wird nur angelegt, wenn Sie einwilligen.
TODO: Grobe Übersicht, links auf gute Ressourcen zum Weiterlernen ([siehe unten](#weitere-hilfe)).
- Sie können eine für Sie passende Sprache unter [Einstellungen > Profil > Einstellungen > Lokalisierung](https://gitlab.ub.uni-giessen.de/profile/preferences#localization) vornehmen.
Da in GitLab jedoch viele Begriffe nur schwer ins Deutsche zu übersetzen sind, kann es vorkommen, dass Ihnen trotz der korrekten Spracheinstellung viele englischsprachige Begriffe begegnen.
TODO: Link zur Führung in GitLab (oder gibt es die nur in EE?).
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
## Git-Workflow mit Offline-Computern
In diesem Abschnitt wird beschrieben, wie Sie einen USB-Stick verwenden, um ein Git-Repository auf einem Laborcomputer ohne Netzwerkzugang zu synchronisieren.
### Warum?
Laborcomputer sind oft nicht mit einem Netzwerk verbunden; ein häufiger Grund dafür ist veraltete/unsichere Software.
Mit Git können Sie trotzdem die Versionskontrolle über Ihren Code behalten, indem Sie ein lokales Speichermedium wie einen USB-Stick verwenden.
Mit Git ist es einfach, Ihren Code zu verwalten und ihn innerhalb und außerhalb des Labors zu synchronisieren.
- Sie können Kopien Ihres Codes an anderer Stelle erstellen (z. B. für Backups), einschließlich der gesamten Versionsgeschichte.
- Sie können sicher sein, dass Sie eine bestimmte Version des Codes ausführen, oder Versionen vergleichen oder zwischen ihnen hin-und-her wechseln.
- Sie können den Code außerhalb des Labors weiter entwickeln, unabhängig davon, welche Version im Labor läuft.
### Wie?
Glücklicherweise ist Git ein _verteiltes_ Versionskontrollsystem, was bedeutet, dass jeder `clone` eines Repositories mit dem gesamten Änderungsverlauf synchronisiert werden kann.
Im folgenden Beispiel werden wir 3 Klone verwenden:
1. Einer auf dem Laborcomputer,
2. einen auf Ihrem Laptop, und
3. einen Zwischenklon auf einem USB-Stick (ein `bare` clone zur Synchronisierung der beiden erstgenannten).
Der Umgang ist sehr ähnlich wie mit einem `remote`-Repository im Internet - mit ein paar technischen Eigenheiten.
- Sie können ein bestehendes Repository auf ein beliebiges Gerät klonen, sei es ein USB-Stick, der Laborcomputer, Ihr Laptop oder eine mobile Festplatte.
- Mit jedem Klon können Sie Commits erstellen und `git pull` und `git push` mit jedem anderen Klon verwenden.
<img src="../images/howto-git-in-lab.svg" alt="Git-Workflow über USB-Stick" width=50% />
Natürlich können Sie auch alle anderen Vorteile von Git nutzen, zum Beispiel:
- Sie können `git branch` verwenden, um zwischen verschiedenen Versionen zu wechseln.
- Sie können auch `git tag` verwenden, um eine bestimmte Version/Commit zu markieren, um sicherzustellen, dass Sie eine bestimmte Version ausführen.
### Beispiel-Workflow
- Hinweis: In diesem Beispiel wird davon ausgegangen, dass Sie [Git Bash](https://git-scm.com/download) auf Ihrem Laptop und auf dem Laborcomputer installiert haben.
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
- Hinweis: Sie müssen die Verzeichnispfade des Beispiels an Ihr System anpassen.
Nehmen wir an, Sie haben ein bestehendes Git-Repository auf Ihrem Laptop, z. B. in einem Ordner namens `example-repo`.
In diesem Beispiel werden wir es über einen USB-Stick mit dem Laborcomputer synchronisieren.
Natürlich können Sie die Rollen Ihres Laptops und des Laborcomputers vertauschen, wenn Sie das Repository auf dem Laptop gestartet haben.
Bitte beachten Sie, dass wenn Sie ein Repository klonen möchten, das LFS-Daten enthält, entweder Zugang zu diesem LFS-Server benötigen (der sich möglicherweise in Ihrem lokalen Netzwerk befindet), oder Sie Git einstellen müssen, dass die LFS-Daten auf dem Laborcomputer ignoriert werden.
Siehe LFS-Dokumentation unter <https://gitlab.ub.uni-giessen.de/jlugitlab/git-lfs-howto>.
#### Einmalige Einrichtung
1. Schließen Sie den USB-Stick an Ihren Laptop an; nehmen wir an, der Stick heißt `E:`.
Öffnen Sie auf Ihrem Laptop _Git Bash_, und klonen Sie das Repository von Ihrem Laptop auf den USB-Stick:
`git clone --bare /pfad/auf/laptop/example-repo/ /e/example-repo/`.
Beachten Sie die Option `--bare`, um keine Arbeitskopie auf dem USB-Stick anzulegen, d.h. der Stick wird als `remote` Speicherort (ohne _"working directory"_) behandelt, allein für das Synchronisieren zwischen Ihrem Laptop und dem Laborcomputer.
2. Konfigurieren Sie auf Ihrem Laptop den neuen Klon auf dem USB-Stick als ein zusätzliches `remote`, genannt `usbstick`: `git remote add usbstick /e/example-repo/`.
3. Entfernen Sie den USB-Stick von Ihrem Laptop und stecken Sie ihn an den Laborcomputer.
Nehmen wir an, dass der Stick auf dem Laborcomputer den Namen `F:` hat.
Öffnen Sie auf dem Laborcomputer _Git Bash_ und klonen Sie das Repository vom USB-Stick in einen geeigneten lokalen Pfad, in dem Sie Ihre Projekte speichern (z. B. `D:\projects`):
```
git clone /f/example-repo /d/projects/example-repo
```
Beachten Sie: Aus der Sicht des Repos auf dem Laborcomputer ist der USB-Stick nun das `origin`-Remote, siehe unten.
4. Wechseln Sie in den Repository-Ordner und konfigurieren Sie Git so, dass Ihr Name und Ihre E-Mail für Commits verwendet werden:
```
cd /d/projects/example-repo
git config user.name "VORNAME NACHNAME"
git config user.email "VORNAME.NACHNAME@FACHBEREICH.uni-giessen.de"
```
#### Täglicher Arbeitszyklus
##### So synchronisieren Sie Änderungen auf dem Laborcomputer mit Ihrem Laptop:
1. Nach Änderungen im Projektarchiv auf dem Laborcomputer verwenden Sie wie gewöhnlich `git add` und `git commit`, um Ihre Änderungen dort zu verfolgen (z.B. im `main`-Zweig).
3. Synchronisieren Sie die Änderungen in das Repository auf dem USB-Stick: `git push origin main`.
Beachten Sie, dass sich Git beim einmaligen Klonen vom USB-Stick diesen Ort als `origin` merkt.
Sie können die `remote`-Speicherorte mit `git remote -v` überprüfen; solange der Pfad des USB-Sticks derselbe bleibt, müssen Sie ihn nicht ändern.
Falls er sich ändert, können Sie ihn mit `git remote set-url origin <NEUER-USB-PFAD>` anpassen.
4. Trennen Sie den USB-Stick sicher vom Laborcomputer und stecken Sie ihn an Ihren Laptop.
Wechseln Sie in das Repo-Verzeichnis auf Ihrem Laptop und Synchronisieren Sie die Änderungen in den `main`-_Branch_: `git pull usbstick main`.
##### So synchronisieren Sie Änderungen auf Ihrem Laptop mit dem Laborcomputer:
1. Machen Sie Änderungen auf Ihrem Laptop und _committen_ sie diese wie üblich mit `git add` und `git commit` (oder beziehen Sie _Commits_ von einer anderen _Git remote_).
2. Schließen Sie den USB-Stick an und _pushen_ Sie die _Commits_, z.B. in den `main`-_Branch_: `git push usbstick main`.
3. Schließen Sie den USB-Stick an den Laborcomputer an, wechseln Sie in das Repository-Verzeichnis (z. B. `cd /d/projects/example-repo`) und synchronisieren Sie die Änderungen vom Stick:
`git pull origin main`.
## Sichtbarkeit von Projekten
Für jedes Projekt können Sie die Sichtbarkeits-Einstellung *private*, *internal* oder *public* auswählen.
Die Sichtbarkeit kann nur von Nutzenden mit der *Owner*-Rolle im Projekt geändert werden (siehe Nutzerrollen [in Projekten](#nutzerrollen-in-projekten) und [in Gruppen](#nutzerrollen-in-projekten)).
- Projekte mit Sichtbarkeit *private* sind nur für die [Mitglieder des Projekts](#nutzerrollen-in-projekten) einsehbar.
Für Gruppenprojekte schließt dies die [Gruppenmitglieder](#nutzerrollen-in-gruppen) ein, je nach deren Rolle.
- Projekte mit Sichtbarkeit *internal* sind für alle Personen mit einem Nutzungskonto einsehbar, die angemeldet sind.
[Bitte lesen Sie hier](Informationen.md#wer-kann-jlu-gitlab-benutzen), auf welchen Personenkreis sich dies bezieht.
- Projekte mit Sichtbarkeit *public* sind für alle Personen ohne Nutzungskonto einsehbar, die auf JLU GitLab zugreifen können.
[Bitte lesen Sie hier](Informationen.md#wer-kann-auf-jlu-gitlab-zugreifen), auf welchen Personenkreis sich dies bezieht.
Für mehr Details lesen Sie bitte die [offizielle Dokumentation (auf Englisch)](https://gitlab.ub.uni-giessen.de/help/public_access/public_access.md#public-access).
## Nutzerrollen in Projekten
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)](https://gitlab.ub.uni-giessen.de/help/user/permissions.md#project-members-permissions).
Für Projekte im Namensraum einer Gruppe haben die Gruppenmitglieder ihre gleichnamigen [Gruppenrolle](#nutzerrollen-in-gruppen) inne; z.B. ist ein *Guest* in der Gruppe auch ein *Guest* in allen Gruppenprojekten, sofern dies nicht durch individuelle Projektrollen überschrieben ist.
<!-- TODO: Kürzen des Teils auf die notwendigen Hinweise wie "Sei vorsichtig wenn du ein Projekt public machst". Außerdem Hinweise wer für Inhalte in Repos veranwortlich ist mit Bezug auf die Nutzungsbedingungen>
<!-- NOTE: Lass uns unten die Berechtigungen der GitLab.com-Verträgen STARTER, PREMIUM, ULTIMATE weglassen, die nicht Teil der Community Edition sind. -->
### Berechtigungen als *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*
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,
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 einem Sentry-Server verbinden. -->
### Berechtigungen als *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 *push*en, 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*
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 *push*en,
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,
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.
<!-- "Audit-Ereignisse ansehen": Ist nicht in der CE... -->
### Berechtigungen als *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](#group_roles) *Owner* innehaben.
Projektmitglieder in der *Owner*-Rolle haben die folgenden zusätzlichen Berechtigungen im Vergleich zur *Maintainer*-Rolle:
*Owner* können die [Sichtbarkeitsstufe](#visibility_projects) 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 [den Nutzungsbedingungen von JLU GitLab](Nutzungsbedingungen.md) alle Nutzenden mit der *Owner*-Rolle für den Inhalt ihrer Projekte verantwortlich sind, auch wenn diese von anderen Nutzenden stammen.
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](Informationen.md) wenn Sie [die Universität verlassen](Informationen.md) oder [ihr Nutzungskonto löschen](#wie-lösche-ich-mein-nutzungskonto), solange die [Gruppe mindestens ein Mitglied enthält](Informationen.md).
Die Zugriffsrechte eines Projekts im Namensraum einer Gruppe hängt von der [Sichtbarkeit](#sichtbarkeit-von-gruppen) und den [Rollen in der Gruppe](#nutzerrollen-in-gruppen) ab.
Außerdem können individuelle Nutzende auch von außerhalb der Gruppe als Projektmitglied zu individuellen Gruppenprojekten hinzugefügt werden.
### Sichtbarkeit von Gruppen
[Wie die Sichtbarkeit von Projekten](#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](Informationen.md#wer-kann-jlu-gitlab-benutzen), was die Sichtbarkeitsstufen *internal* und *public* im Fall von JLU GitLab bedeuten.
### Nutzerrollen in Gruppen
Wenn Sie Nutzende als Gruppenmitglieder hinzugefügen, müssen Sie ihnen auch eine Gruppenrolle zuordnen:
Wie die [Nutzerrollen in Projekten](#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](#nutzerrollen-in-projekten) 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)](https://gitlab.ub.uni-giessen.de/help/user/permissions.md#group-members-permissions):
<!-- NOTE: Let's below exclude the permissions from subscription plans STARTER, PREMIUM, ULTIMATE that are not part of the Community Edition. -->
*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 den [Nutzungsbedingungen von JLU GitLab](Nutzungsbedingungen.md) 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
TODO: Beschreibung der Einstellungen von Commit-Namen und -Emailadresse (in GitLab und lokal), Profil und Aktivitäten unsichtbar machen, ...
Bevor Sie [die Universität verlassen](Informationen.md#was-passiert-wenn-ich-die-jlu-verlasse) oder [Ihr Nutzungskonto löschen](#wie-lösche-ich-mein-nutzungskonto), 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](Informationen.md#was-passiert-mit-meinen-daten-wenn-mein-konto-gelöscht-wird).
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 Tickets, Wiki, usw. mit ein.
## Wie lösche ich mein Nutzungskonto?
Sie können Ihr Nutzungskonto jederzeit löschen, indem Sie [*Einstellungen > Konto > Konto löschen*](https://gitlab.ub.uni-giessen.de/profile/account) 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](Informationen.md#was-passiert-mit-meinen-daten-wenn-mein-konto-gelöscht-wird);
mit ein paar [letzten Schritten](#letzte-schritte) 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).
TODO: Mehr nützliche Links, evtl. in Kategorien; GitLab selbst hat noch eine Menge.
- [Die offizielle Nutzerhilfe für JLU GitLab (auf Englisch)](https://gitlab.ub.uni-giessen.de/help/user/index.md).
- [Kostenloses Online-Buch *Pro Git*](https://git-scm.com/book/de), teilweise auf Deutsch übersetzt