Client-Installation

Der empfohlene Git-Client für Windows ist Git for Windows (ehemals msysGit). Git for Windows bietet neben den notwendigen Kommandozeilen-Werkzeugen auch eine (teilweise etwas rudimentäre) grafische Oberfläche namens Git GUI an, sowie eine Integration ins Kontextmenü des Windows Explorers. Da die relevanten Kommandozeilen-Werkzeuge installiert sind, funktioniert in der Regel aber auch die Git-Integration in anderen Werkzeugen, insbesondere die Eclipse-Integration mittels EGit. Zur Arbeit mit den Kommandozeilen-Werkzeugen ist die Verwendung der Git Bash hilfreich: In der normalen Windows-Eingabeaufforderung funktionieren einige Kommandos u.U. nicht vollständig, und die Benutzerfreundlichkeit der Git Bash ist allgemein besser.

Aus Erfahrung müssen wir von der Installation von TortoiseGit leider dringend abraten – TortoiseGit ließ sich nicht für Anmeldung mittels SSH-Keys einrichten, und beschädigte bei seiner Installation die msysGit-Installation dahingehend, dass mit msysGit auch kein Zugriff mehr auf das Repository möglich war. Sollten Sie andere Erfahrungen gemacht haben und eine zuverlässige Möglichkeit kennen, TortoiseGit mit Authentifizierung über SSH einzurichten, oder wissen wie man die msysGit-Installation danach möglichst einfach wieder reparieren kann, kontaktieren Sie uns bitte unter git@uni-konstanz.de.

Nach den üblichen Abfragen zum durchklicken (Lizenz, Ordner für die Installation, Eintrag im Startmenü) kann man die Komponenten auswählen. Die Standard-Auswahl ist empfehlenswert: Die Eniträge ins Kontextmenü erlauben die Arbeit direkt aus dem Windows Explorer heraus. "Associate .sh files to be run with Bash" ist nicht unbedingt nötig, sollte aber nicht schaden und ist für die Zusammenarbeit mit nicht-Windows-Nutzern u.U. nützlich.


Git kann sich in die PATH-Umgebungsvariable eintragen. Das ist u.A. für die Eclipse-Integration erforderlich und dringend zu empfehlen. Hier macht eigentlich nur der Standard Sinn: Mit "Use Git from Git Bash only" funktioniert EGit (Eclipse) nicht, und die letzte Option kann erhebliche Probleme mit anderen Anwendungen verursachen, insbesondere wenn Batch-Skripte benutzt werden. Die Warnung ist aus gutem Grund rot.


Git und Windows benutzen inkompatible Konventionen für Zeilenumbrüche. "Checkout Windows-style, commit Unix-style" erlaubt das direkte Bearbeiten aller Textdateien mit so gut wie allen Windows-Anwendungen. Die meisten Entwicklungswerkzeuge kommen aber auch mit "Unix-style" Zeilenenden zurecht, so dass "Checkout as-is, commit Unix-style" in der Regel funktioniert. Notepad zeigt solche Dateien aber auch im Jahr 2016 noch falsch an.

Bitte wählen Sie hier nicht die Option "Checkout as-is, commit as-is"! Windows-Zeilenenden führen in Git unter allen anderen Betriebssystemen zu kleinen aber äußerst nervigen Problemen (Beispiel: git diff zeigt immer alle Zeilen einer Datei als geändert an), so dass diese Option bestenfalls geeignet ist die Kollegen zu ärgern, und/oder um sich als ignoranter Windows-Nutzer zu profilieren.

Nach diesem Schritt fragt der Installer noch, ob für Git entweder MinTTY oder die Windows-Konsole verwendet werden soll. Beides funktioniert; MinTTY ist bequemer und zeigt Umlaute korrekt an, dafür ist die Windows-Konsole eventuell etwas gewohnter.


Der "file system cache" beschleunigt Git-Kommandos und ist empfehlenswert.

Der Credential Manager ist für GitLab nicht erforderlich und auch nicht nützlich, weil der Zugriff auf das Repository über SSH-Keys läuft und der Credential Manager keine SSH-Keys unterstützt. Richten Sie stattdessen einfach einen SSH-Key bei GitLab ein, wie im folgenden beschrieben.


SSH-Key erstellen und einrichten

Im Startmenü sollte sich ein neues Programm namens "Git GUI" befinden.


Die Git GUI bietet recht umfangreiche Funktionen auf Repositories. Wenn sie aus dem Startmenü gestartet wird, ist die Oberfläche aber sehr minimalistisch und erlaubt zunächst nur die Auswahl eines Repositories. Etwas versteckt, nämlich unter Help → Show SSH Key, bietet die Git GUI aber auch ein sehr nützliches Werkzeug, um bequem einen SSH Key zu erstellen.


Nach einer Neuinstalation wird hier in der Regel noch kein Key angezeigt. Das lässt sich mit einem Klick auf "Generate Key" ändern.

Die Git GUI fragt hier nach einem Passwort, mit dem der SSH-Key geschützt werden soll. Dieses Passwort ist optional, hat nichts mit Ihrem GitLab-Passwort zu tun, und sorgt im allgemeinen nur für einen lästigen Passwort-Dialog bei jedem Zugriff auf GitLab. Dieses Passwort kann es Schadsoftware oder unberechtigten Personen, die Zugriff auf Ihren Rechner bekommen, erschweren (aber nicht zuverlässig verhindern) in Ihrem Namen auf ihr GitLab-Repository zuzugreifen. Insofern ist es sinnvoller, die Ursache (Schadsoftware usw.) zu beseitigen.

Sobald der Key erzeugt wurde, oder wenn von einer vorherigen Installation schon ein Key vorhanden ist, wird "Generate Key" deaktiviert. Sollte schon ein Key vorhanden sein, ist es sinnvoll diesen weiterzuverwenden. Mehrere SSH-Keys auf einem Rechner sind möglich, aber sehr umständlich zu verwalten.


Kopieren Sie den SSH-Key in die Zwischenablage ("Copy to Clipboard") und kopieren Sie ihn in in GitLab unter Profile Settings → SSH Keys → Add SSH Key in das Feld "Key". "Title" wird automatisch eingetragen; bei Bedarf sollten Sie den Titel aber so ändern, dass Sie den Rechner, auf dem der Key erzeugt wurde, daran identifizieren können.

Sollte der Key, oder der Rechner / Laptop, einmal abhanden kommen, können Sie den betroffenen Key schnell wieder entfernen. Das bringt den Key, und insbesondere den Rechner, nicht zurück, aber es kann unberechtigten Schreibzugriff auf Ihr GitLab-Repository verhindern. Lesezugriffe werden dann zwar ebenfalls abgelehnt; da beim Klonen aber eine vollständige Kopie des Repositories erstellt wird, befinden sich in der Regel sowieso bereits alle Daten aus dem Repository auf dem Rechner. Abhilfe schaffen hier nur Werkzeuge zur Festplattenverschlüsselung.


Konfiguration der Git GUI

Wenn die Git GUI in einem Repository gestartet wird (Rechtsklick → Git GUI here, oder im Hauptfenster ein Repository öffnen), wird standardmäßig die Oberfläche zum Commit angezeigt. Viele weitere Funktionen befinden sich in den Menüs.

"Rescan" überprüft das Repository auf Veränderungen, die dann mittels "Stage Changed" (alle Änderungen) oder "Commit → Stage to Commit" (nur bestimmte Änderungen) für den Commit markiert werden können. Nach Eingabe einer nüzlichen Commit-Beschreibung können die Änderunge mittels "Commit" dem Repository hinzugefügt werden. Diese Änderungen sind zunächst nur lokal; erst mit einem Klick auf "Push" werden sie auf GitLab übertragen.

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.


Die Einstellungen sind eindeutig überladen, allerdings sollten die meisten Standard-Werte gut geeignet sein. Zwei Felder müsser aber konfiguriert werden: "User Name" (Ihr Name) und "Email Address", ansonsten erlaubt Git keine Commits. Wir empfehlen, als Email-Adresse die universitäre Email-Adresse zu verwenden.