-[Einführung in die Informationstechnik](https://www3.tuhh.de/itbh/lehre/inf1-sose2019/)
---
# Hands-on!
+++
## GitLab von außen
https://collaborating.tuhh.de/
- Projekte
- Benutzer_innen
- Gruppen
+++
## GitLab von innen
+++
## Registrieren und Anmelden
https://collaborating.tuhh.de/
- keine Zugangsbeschränkung an der TUHH
- kein Funktionsaccount nötig
- internationale Kollaboration möglich
-**Einschränkung:** Nicht-TUHH-Mailadressen dürfen keine eigenen Projekte anlegen.
+++
## Profil und Einstellungen
-**Profile:** Avatar, Bio und verbundene Accounts
-**Account:** Änderung des Benutzernamens
-**Emails:** Zusätzliche Emails
-**Notifications:** Einstellen der Dichte von Meldungen
-**Preferences:** Aussehen der Oberfläche
+++
## Projekt anlegen
- individuelle Projekte aus dem professionellen Kontext (Daten, Code, Text)
-**Achtung!***Visibility Level* entscheidet über Sichtbarkeit nach außen
+++
**Aufgabe**
Legen Sie ein eigenes Projekt in Ihrem Account an!
+++
## Projekteinstellungen - General
-**Permissions:***Welche* Bereiche des Projekts werden genutzt? *Wer* darf die Bereiche nutzen?
-**Advanced:** umbenennen, übertragen, löschen
+++
## Projekteinstellungen - Members
- Hinzufügen von Beitragenden
- Zuweisung von Rollen
+++
## Exkurs: Markdown
https://dillinger.io/
- einfache Auszeichnungssprache für Texte
- kann mit HTML und LaTeX angereichert werden
- weit verbreitet im Netz
- kann mit [Pandoc](http://pandoc.org/) in zahlreiche Zielformate gewandelt werden
+++
## Weiter: Arbeiten im Projekt
- Hinzufügen einer README.md
- Beschreibung des Projekts
- Beispiele guter READMEs in namhaften Projekten bei GitHub
---
## Projektmanagement
+++
## Gruppen
- Mit Gruppen in GitLab können Teams gebildet werden
- Gruppen können Untergruppen (*subgroups*) haben
- Projekte können in/für Gruppen angelegt werden
+++
## Erste Schritte Projektmanagement
- Projektdefinition
- Projektplanung
- Strukturierung des Projekts
- Sammlung und Darstellung von Aufgaben/Arbeitspaketen
- Aufgabenverteilung
+++
## Das Wiki
- Jedes Projekt hat ein **Wiki**
- Inhalte im Wiki werden mit Markdown notiert
- Das Wiki ist ebenfalls ein Git-Repository und bietet alle Vorteile der dezentralen Bearbeitung
- Wikis eignen sich sehr gut zur
- Informationssammlung
- Projektdokumentation
- Hacks zur (fast) finalen Dokumentenerstellung mit *pandoc*, *GitBook* u.ä.
+++
## Issues
- Festhalten von Arbeitsaufträgen, User Storys, Fehlerberichten, Kundenwünschen etc.
- Diskussion über die Details
- Entsprechend der Idee von *User Storys* können mit Checkboxen *Tasks* definiert werden. Diese beschreiben die konkreten Aufgaben, die zum Einlösen der Story erledigt werden müssen.
+++
## Label
- Label sind frei definierbare "Etiketten" für Issues und ermöglichen übergreifende Ordnungskonzepte
- Aus Labeln können Listen im Board erstellt werden
+++
## Das Board
- Jedes Projekt hat ein Board
- sinnvolle Strukturierung von Issues z.B. gemäß einer Projektmanagementmethode (Kanban, Scrum o.ä.)
+++
## Zuweisung von Issues
- Issues können entsprechend der Aushandlung zwischen den Beitragenden zugewiesen werden
- Issues können an einen *Milestone* oder eine individuelle Deadline gebunden werden
<arel="license"href="http://creativecommons.org/licenses/by/4.0/"><imgalt="Creative Commons Lizenzvertrag"style="border-width:0"src="https://i.creativecommons.org/l/by/4.0/88x31.png"/></a><br/>Diese Präsentation von Axel Dürkop (ITBH an der TUHH) ist lizenziert unter einer <arel="license"href="https://creativecommons.org/licenses/by/4.0/deed.de">Creative Commons Namensnennung 4.0 International Lizenz</a>.
Nutzen Sie diese Präsentation gern im Rahmen der genannten Lizenz, um auch anderen die Vorzüge von GitLab näher zu bringen.
---
# Reserve
+++
## Branches
- Branches sind eigenständige Entwicklungslinien
- Ergebnisse aus Branches können in andere Branches **gemergt** werden
- Es ist sinnvoll, **Branches aus Issues** zu erstellen
- Branches sollten nach dem Mergen gelöscht werden
**Branches kosten nichts und können nach Herzenslust jederzeit auch zum Experimentieren und Spielen erstellt werden**
+++
## Merge Requests
-**Merge Requests (MR)** sind zu verstehen als
*Antrag auf Übernahme von Beiträge aus einem Quellbranch in einen Zielbranch*
- MR können
1. innerhalb eines Projekts von einem Branch zu einem anderen gestellt werden.
1. von einem geforkten Projekt (Kopie) auf das Quellprojekt (Original) gestellt werden.
- MRs haben großes Potential für die Qualitäts-kontrolle durch die Entwicklergemeinschaft
+++
## Merge
-**mergen** bezeichnet den Vorgang, einen *Commit* mit einem anderen zu verschmelzen
+++
## Forks
Als **Fork** wird die Kopie eines Repositorys bezeichnet.
+++
**Aufgabe**
Forken Sie das Repository dieser Präsentation in Ihren Account!
+++
## Review Apps
GitLab bietet die Möglichkeit, auf Basis von Branches so genannten **Review Apps** zu generieren. Hierbei kommen Virtualisierungstechniken wie [Docker](https://de.wikipedia.org/wiki/Docker_(Software)) zum Einsatz.
**Review Apps** sind (vollständige) Anwendungen/Artefakte auf Basis von Branches. Sie dienen dazu, dem Kunden bzw. dem Team eine Vorschau auf die Implementierung einer Funktion oder Anforderung zu geben.
+++
## GitKraken
-[grafischer Client](https://www.gitkraken.com/) zur lokalen Verwaltung von Dateien
- Anbindung an entfernte Git-Dienste wie GitHub, GitLab, Bitbucket u.a.
