Git
Einführung
Git ist ein verteiltes Versionskontrollsystem, das Änderungen an beliebigen Computerdateien verfolgt und in der Regel für die Koordinierung der Arbeit von Programmierern verwendet wird, die während der Softwareentwicklung gemeinsam an Quellcode arbeiten. Zu seinen Zielen gehören Geschwindigkeit, Datenintegrität und die Unterstützung verteilter, nichtlinearer Arbeitsabläufe (Tausende von parallelen Zweigen, die auf verschiedenen Computern laufen).
Seit seiner Entwicklung hat sich Git zum beliebtesten verteilten Versionskontrollsystem entwickelt. 2022 gaben fast 95 % der Entwickler an, es als ihr primäres Versionskontrollsystem zu verwenden. Es gibt viele beliebte Angebote für Git-Repository-Dienste, darunter GitHub, SourceForge, Bitbucket und GitLab.
An der FH Münster wird für die Verwaltung von Code ein eigenes GitLab angeboten. Dies ist über git.fh-muenster.de (auch außerhalb des FH Netzes) per FH Login erreichbar.
Erstellen eines GitLab Repositories
Um das FH GitLab für die Verwaltung von R Code in RStudio bzw. der Posit Workbench zu verwenden, sollte zunächst ein entsprechendes Projekt in GitLab erzeugt werden. Hierzu kann auf der Startseite (vgl. Abbildung 1) ein neues Projekt per Klick erstellt werden.
Die Erstellung eines Repositories lässt sich zunächst am einfachsten über ein leeres Projekt starten (vgl. Abbildung 2).
Anschließend müssen – wie in Abbildung 3 gezeigt – diverse Angaben für das Projekt gemacht werden, wie beispielsweise ein Name und ob das Projekt öffentlich verfügbar sein soll (“Public”), nur für FH Angehöre (“Internal”) oder nicht öffentlich (“Private”).
Anschließend ist das Projekt erstellt (vgl. Abbildung 4).
Zusammenarbeit in GitLab Projekten
In GitLab lassen sich für ein Projekt weitere Personen zur Zusammenarbeit einladen. Im Hauptmenü des Projekt ist dies unter dem Punkt “Members” möglich (vgl. Abbildung 5).
Den Mitgliedern des Projekts lassen sich unterschiedliche Rollen mit entsprechenden Rechten zuweisen (vgl. Abbildung 6). In der Dokumentation von GitLab lassen sich die entsprechenden Berechtigungen der Rollen nachlesen.
Verwendung von GitLab mit RStudio bzw. Posit Workbench
Im Folgenden finden Sie eine Kurzbeschreibung über die Arbeit mit GitLab in RStudio bzw. Posit Projekten. Sehr detailliert geht das Buch bzw. die Webseite Happy Git and GitHub for the useR auf die Verwendung des Versionskontrollsystems Git für R Programmierer ein. Viele Erläuterungen beziehen sich hierbei auf GitHub, lassen sich aber leicht auf GitLab übertragen.
Klonen eines GitLab Projekts in RStudio/Posit
Um das Projekt in RStudio bzw. der Positworkbench zu klonen, ist der entsprechende Link in GitLab zu kopieren. Abbildung 7 zeigt zwei unterschiedliche Möglichkeiten:
- Clone with SSH: Für diese Variante ist zunächst auf dem Zielgerät (in der Regel die Posit Workbench oder der eigene Rechner) ein SSH Schlüsselpaar zu erstellen. Sobal die Schlüssel erzeugt und in den entsprechenden Systemen hinterlegt sind, kann die Synchronisierung ohne weitere Eingabe von Nutzername und Passwort erfolgen. Eine detaillierte Beschreibung zu Erstellung der SSH Keys finden sich hier.
- Clone with HTTPS: Für diese VariantekKann einfach die FH Kennung und das entsprechende Passwort verwendet werden. Diese müssen allerdings bei jeder Synchronisierung eingegeben werden.
Zusammenfassend lässt sich also festhalten, dass das Klonen per SSH einen gewissen Initialaufwand erfordert, falls noch kein Schlüsselpaar vorliegt. Ist dies allerdings einmal erledigt, vereinfacht sich im weiteren Verlauf der Synchronisierungsprozess, da keine Passworteingabe mehr erforderlich ist.
Ein Projekt lässt sich von allen Mitgliedern klonen. Zum Klonen des GitLab Projekts in RStudio bzw. der Posit Workbench, muss hier ein neues Projekt erstellt werden. Hierzu wird bei der Erstellung des neuen Projekts als Quelle “Version Control” ausgewählt (vgl. Abbildung 8).
Dort wiederum ist dann git als Versionskontrollsystem auszuwählen (vgl. Abbildung 9)
Zum Abschluss der Erstellung wird der zuvor kopierte Link zum GitLab Respository eingefügt und ein Ordner für die Ablage des Codes angegeben (vgl. Abbildung 10).
In der anschließenden Eingabeaufforderung gibt man noch die FH Kennung und das dazugehörige Passwort an. Anschließend werden die Inhalte des GitLab Repositories in das Verzeichnis des RStudio bzw. Posit Projekts geklont.
In dem Projekt ist nun im oberen rechten Abschnitt ein Reiter mit dem Namen “Git” zu sehen (vgl. Abbildung 11). In diesem Reiter lässt sich die Interaktion mit dem GitLab Repository steuern.
Stage, Commit, Pull, Push
Um einen Zwischenstand von Änderungen zu sichern, zu dem man später jederzeit zurückkehren kann, erstellt man einen sogenannten “Commit” mit einem Klick auf den gleichnamigen Button. Es öffnet sich das in Abbildung 13 gezeigt Fenster. Das anschließende Vorgehen ist wie folgt:
- Auswahl der Dateien mit Änderungen, die für die Zwischenspeicherung berücksichtigt werden sollen (sog. Staging) mit dem Button “Stage”.
- Verfassen einer “Commit message” zur Dokumentation der Bedeutung der Änderungen. Diese Message darf nicht leer sein und sollte unbedingt sinnstiftend gefüllt werden, um später die Änderungen nachvollziehen zu können.
- Anschließend wird der Commit über einen Klick auf den entsprechenden Button bestätigt.
Sollten Änderungen an Dateien zurückgenommen werden, gelingt dies über “Revert”.
Nach dem Commit sind die Änderungen zunächst lokal festgehalten und noch nicht mit dem GitLab Server synchronisiert. Um die Änderungen in das GitLab Repository zu schieben, nutzt man einen “Push” mit einem Klick auf den entsprechenden Button. Änderungen, die im Repository vorgenommen wurden, aber noch nicht lokal verfügbar sind, lassen sich über einen “Pull” beziehen. In der Regel ist vor dem Push ein Pull auszuführen, um sicher zu stellen, dass das lokale Repository auf dem aktuellen Stand ist.
Der Prozess zur Arbeit mit Git als Versionskontrollsystem wird in Abbildung 12 zusammengefasst.
Beim Push von Änderungen kann es zu Konflikten kommen, insbesondere in der Zusammenarbeit mit anderen Mitgliedern, falls an derselben Stelle des Codes unterschiedliche Arbeitsstände lokal und im Repository vorliegen. In diesem Fall ist der Konflikt manuell zu lösen. Einige nützliche Hinweise dazu finden Sie hier
Verwendung von GitLab mit JupyterHub
Klonen eines GitLab Projekts in JupyterHub
Inhalt kommt demnächst…