GitLab-Beta-Dienst

Die Universität Konstanz betreibt unter https://git.uni-konstanz.de eine zentrale GitLab-Instanz. Diese befindet sich derzeit im Beta-Betrieb und steht allen Mitarbeiten und Studenten der Universität zur Verfügung. Im Beta-Betrieb wird keine ununterbrochene Verfügbarkeit des Dienstes garantiert.

Die Anmeldung für GitLab erfolgt über Shibboleth. Bitte wählen Sie dazu auf der Login-Seite links den Button für Ihre Heimat-Institution aus, hier beispielsweise die Universität Konstanz. Sie werden dann zum Login auf die Seiten des RZ weitergeleitet. Der Login mit Benutzername und Passwort auf der rechten Seite ist nur für Gäste möglich!

Der Zugriff auf Repositories erfolgt über SSH-Keys. Anleitungen zur Client-Installation samt Einrichtung eines SSH-Keys haben wir für Sie zusammengestellt:


Windows Linux und Mac OS X

Der Zugriff auf Repositories mit Benutzername / Passwort ist nicht möglich. Verwenden Sie daher bitte immer die Repository-URL im SSH-Format (git@git.uni-konstanz.de:…); die HTTPS-URL (https://git.uni-konstanz.de/…) funktioniert nicht! Sollte Ihr Git-Client dennoch nach einem Passwort fragen, ist normalerweise entweder der SSH-Key nicht richtig eingerichtet, er wird nicht gefunden (passiert besonders gerne in Eclipse), oder die Repository-URL ist falsch (muss mit git@git.uni-konstanz.de: anfangen).

Einzige Ausnahme bilden öffentliche Projekte, die über HTTPS geklont werden können; auch in diesem Fall wird jedoch kein Benutzername oder Passwort abgefragt.

Zum Login: GitLab (Beta)

Kurze Einführung in Git

Diese Seite kann keine vollständige Einleitung in Git geben, allerdings gibt es zahllose Einführungen in Git mit verschiedenem Maß an Umfang und Vollständigkeit. Ein relativ kurzer, interaktiver Einführungskurs in Git, der die wichtigsten Schritte in Git umfasst, wird beispielsweise von Codecademy angeboten. Für Codecademy ist allerdings eine (kostenlose) Anmeldung erforderlich, und das Abbestellen nerviger Emails empfehlenswert.

Die wichtigsten Kommandos für Git sind:

  • git irgendwas --help öffnet die Dokumentation zu "irgendwas".
  • git clone git@git.uni-konstanz.de:user/projekt.git erstellt eine lokale Arbeitskopie des entfernten Repositories, auf der alle weiteren Arbeiten ausgeführt werden können.
  • git add irgendwas.txt merkt die Datei "irgendwas.txt" in ihrem aktuellen Zustand zum Commit vor. Wenn Sie weitere Änderungen an der Datei vornehmen, werden diese Änderungen erst zum Commit vorgemerkt, wenn Sie "git add irgendwas.txt" erneut ausführen. So ist sichergestellt, dass nicht versehentlich unbeabsichtigte Änderungen ins Repository hinzugefügt werden.
  • git reset irgendwas.txt entfernt die Vormerkung für die Datei "irgendwas.txt", d.h. macht "git add" rückgängig.
  • git commit erstellt einen Commit mit den aktuell vorgemerkten Änderungen. Hierfür ist eine kurze Textuelle Beschreibung der Änderungen nötig; siehe unten. Der neue Commit ist zunächst nur lokal verfügbar!
  • git push überträgt alle lokalen Commits auf GitLab. Erst danach sind Commits für andere Projektmitglieder sichtbar.
  • git pull überprüft GitLab auf neue Commits. Falls neue Commits anderer Projektmitglieder verfügbar sind, werden diese heruntergeladen und die Änderungen lokal angewandt.

Gute Commit-Beschreibungen

Eine Commit-Beschreibung sollte immer aus einer kurzen und aussagekräftigen Zusammenfassung der Änderunge in der ersten Zeile bestehen. Alles andere macht es sehr schwer, Änderungen wieder zu finden. Falls erforderlich, können nach einer Leerzeile weitere Erläuterungen zum Commit folgen, beispielsweise eine Begründung für die Änderungen oder eine genauere Beschreibung. Die Erläuterungen sollten nach ~76 Zeichen umgebrochen werden, können ansonsten aber beliebig umfangreich sein. Lediglich die Leerzeile zwischen Kurzbeschreibung und Erläuterungen ist zwingend erforderlich, da einige Git-Kommandos ansonsten möglicherweise nicht korrekt funktionieren.

Bei der Verwendung von Git ist es generell ratsam, mehrere kleine Commits zu erzeugen, die jeweils zusammengehörende Änderungen umfassen. Es ist zwar möglich, am Ende des Arbeitstags einfach alle Änderungen zu committen – das macht es aber im Nachhinein extrem schwer zu identifizieren, was in diesem Commit eigentlich geändert wurde, weil viele verschiedene Änderungen miteinander vermischt sind. Das wiederum kann sich bei der Suche nach Bugs rächen.

Auflösen von Merge-Konflikten

Ein Merge kann bei einem "git pull" auftreten, wenn zwei Projektmitglieder die gleiche Datei bearbeitet haben, insbesondere wenn die gleichen Zeilen in dieser Datei bearbeitet wurden. Wenn beispielsweise die Zeile

Pluto is the ninth planet in the solar system.

von zwei Projektmitgliedern durch etwas anderes ersetzt wird, kann Git die Änderungen nicht selbst zusammenführen – wo das möglich ist, führt Git den Merge ohne Interaktion mit dem Benutzer durch. Git markiert die betroffenen Zeilen dann wie folgt:

<<<<<<< HEAD
Pluto is just another Kuiper Belt Object.
=======
Pluto is still a proper planet!
>>>>>>> new-mexico

In diesem Fall müssen Sie also die Datei im Editor öffnen und die beiden Änderungen zusammenführen. Im vorliegenden Fall ist das einfach: Der gesamte Block (inklusive der Zeilen mit <<<<<<< und >>>>>>>) sollte ersetzt werden durch

Pluto is just another Kuiper Belt Object.

Bei Programmcode ist es manchmal erforderlich, neuen Code zu schreiben, der beide Änderungen unterstützt; die Analogie dazu wäre, den Block zu ersetzen durch einen faulen Kompromiss:

Pluto is a dwarf planet.

Wie alle anderen Änderungen muss diese Änderung mittels "git add" zum Commit vorgemerkt werden; ein folgendes "git commit" erstellt einen Merge-Commit, in dem die Auflösung des Konflikts dokumentiert wird. Das kann dabei helfen, denselben Konflikt in Zukunft automatisch zu lösen.

Kommandotabelle Subversion → Git

SVNGit
svn commit
git commit -a
git push
Nur empfehlenswert, wenn ausschließlich zusammengehörende Änderungen vorhanden sind.
svn commit a.txt b.txt …
git add a.txt b.txt …
git commit
git push
svn update
git pull
svn add a.txt
git add a.txt
Kein direktes Äquivalent: "svn add" merkt eine Datei quasi für alle zukünftigen Commits vor. Das wird von Git nicht unterstützt.
svn rm a.txt
git rm a.txt
svn status
git status
"git status" dient auch dazu, die zum Commit vorgemerkten Änderungen anzuzeigen.
svn revert a.txt
git checkout a.txt
"git checkout" kann auch benutzt werden, um Dateien aus älteren Commits wiederherstellen.
svn mv a.txt b.txt
git mv a.txt b.txt
mv b.txt temp.txt
svn revert a.txt
svn mv a.txt b.txt
mv temp.txt b.txt
git add -A a.txt b.txt
Lästiger Fehler in Subversion: Datei einfach umbennannt anstatt "svn mv" zu benutzen.
svn cp a.txt b.txt
cp a.txt b.txt
git add b.txt
Dass b.txt eine Kopie von a.txt ist, erkennt Git anhand der Ähnlichkeit der Dateien von selbst.
svn checkout
git clone

Über GitLab

GitLab bietet moderne Versionsverwaltung mit Git für Quellcode oder andere Anwendungen mit moderat großen, möglichst textuelle Datenmengen – Git bietet für große und/oder nicht-textbasierte Datenformate kaum Vorteile. Zusätzlich zur reinen Versionierung unterstützt GitLab  die Zusammenarbeit durch grundlegene Projektmanagement-Funktionalität über den integrierten Issue Tracker, und stellt in jedem Projekt ein Wiki für Dokumentation bereit. Die Mitarbeiter eines Projektes, sowie deren Rechte, können bequem in der Webschnittstelle verwaltet werden.

Der GitLab-Dienst soll für einfache Pojekte, insbesondere im Bereich der Software-Entwicklung in Forschung & Lehre, in einer leicht zu bedienenden Oberfläche die wichtigsten Aufgaben zur Verwaltung des Projekts zur Verfügung stellen. Bitte beachten Sie jedoch folgende Einschränkungen:

  • GitLab bietet flexible Möglichkeiten zur Zugriffskontrolle, speichert die Daten aber unverschlüsselt ab und ist daher für hoch vertrauliche Daten nicht geeignet. Insbesondere dürfen keinesfalls medizinische Daten oder ähnliches auf dem Dienst gespeichert werden!
  • Größere Datenmengen sind auf bwSync&Share oder dem Fileserver besser aufgehoben als in einem Git-Repository; zudem sind diese Dienste bei großen Dateien erheblich schneller und bequemer zu benutzen.
  • Für die Verwaltung komplexer Projekte bietet das Projektmanagement-Werkzeug Redmine wesentlich mehr Funktionalität als der in GitLab integrierte Issue Tracker.