© Burmakin Andrey, 123RF

Wer Git komplexere Projekte anvertraut, benötigt mitunter eine freie Sicht auf die Abhängigkeiten und Branches. Zahlreiche GUIs versprechen in dieser Sache Abhilfe. Aus dem mannigfaltigen Angebot hat sich die Redaktion Gitk, Gitg, Git-Gui und Gitahead herausgepickt und getestet.

Grafische Benutzeroberflächen für die Versionsverwaltung Git visualisieren in erster Linie Branches und unterschiedliche Versionsstände. Entwickler behalten so den Stand ihres Projekts besser im Blick. Zudem lässt sich Git mit ihrer Hilfe leichter bedienen, weil die Programmierer sich keine kryptischen Git-Kommandos merken müssen.

Dank der großen Beliebtheit von Git buhlen inzwischen zahlreiche GUIs um Anwender, darunter auch kommerzielle. Viele Nutzer wissen nicht, dass Git mit Gitk [1] und Git-Gui [2] bereits zwei GUIs im Gepäck hat. Zwar gehören beide zum offiziellen Lieferumfang von Git, doch viele Distributionen lagern sie in eigene Pakete aus. Unter Ubuntu 18.10 müssen Anwender etwa die Pakete »git-gui« respektive »gitk« installieren. Der Code für beide GUIs steckt zudem in externen Projekten. Die Git-Entwickler übernehmen stets die letzte stabile Version in ihren Zweig.

Wie beide GUIs gegenüber den anderen abschneiden, soll der folgende Vergleich mit den freien Konkurrenten Gitahead [3] und Gitg [4] offenbaren.

Gitk

Gitk [1] basiert auf der Skriptsprache Tcl und dem Toolkit Tk. Entsprechend altbacken wirkt die Optik des Hauptfensters. Die letzte Aktualisierung der Software erfolgte zudem vor zwei Jahren. Gitk visualisiert nur die Git-History (Abbildung 1), wobei Anwender es direkt im entsprechenden Projektverzeichnis aufrufen. Mehrere Projekte kann das Tool nicht verwalten und auch nicht gegenüberstellen. Links oben im Hauptfenster erscheint die Ansicht aller Branches, in der auch die Merges und Commits auftauchen.

Abbildung 1: Gitk erschlägt den Anwender mit Informationen und dient im Wesentlichen nur zur Visualisierung der Branches und Commits.

Ein Klick auf einen Commit zeigt links unten das Changelog mitsamt den vorgenommenen Änderungen. Rechts unten erscheinen die geänderten Dateien, rechts oben die Namen der zuständigen Personen.

Gleich zwei Suchfunktionen helfen beim Aufstöbern von Informationen: Eine der beiden durchkämmt das gerade geöffnete Changelog und die Änderungen, ihre Kollegin wühlt sich durch die Commits. Nur die zweite Suchfunktion wertet auch reguläre Ausdrücke aus. Beide heben allerdings schon bei der Eingabe eines Suchbegriffs entsprechende Fundstellen farbig hervor.

Anwender dürfen so genannte Ansichten anlegen, um die Darstellung auf bestimmte Kriterien einzuschränken. So lässt sich beispielsweise eine Ansicht erstellen, die ausschließlich die Commits von »Tim Schürmann« anzeigt. Diese Ansichten öffnet Gitk allerdings nicht in separaten Fenstern, vielmehr müssen Anwender umständlich über ein Menü dorthin wechseln.

Git-Gui

Das Git beiliegende Git-Gui (Abbildung 2) basiert ebenfalls auf Tcl und Tk. Wie bei Gitk erfolgt der Aufruf direkt im entsprechenden Projektverzeichnis über das Git-Kommando »git gui«. Im Gegensatz zu Gitk vereinfacht Git-Gui [2] ausschließlich die Arbeit mit den Git-Kommandos. Die grafische Darstellung der Branches überlässt das Tool der Kollegin Gitk, die ein entsprechender Menüpunkt auf den Bildschirm holt.

Abbildung 2: Git-Gui bietet eine aufgeräumte Oberfläche, verwirrt aber mit eigenwilligen deutschen Übersetzungen und deckt nicht alle Git-Features ab.

Die deutschsprachige Fassung der Benutzeroberfläche verwendet übrigens einige für Git-Anwender ungewohnte Übersetzungen. Beispielsweise lassen sich Änderungen »eintragen« und »versenden« – die etablierten englischen Begriffe wären »commit« und »push«.

Im Hauptfenster zeigt Git-Gui links die geänderten Dateien, rechts oben die Änderungen in der ausgewählten Datei (Abbildung 3). Im unteren Bereich hinterlegt der Entwickler einen Kommentar und erzeugt über entsprechende Schaltflächen schnell einen Commit.

Abbildung 3: Git-Gui kann einzelne Dateien in diesem File Viewer anzeigen, der zudem eine interaktive Blame-Ansicht bietet.

Sind die unter Linux verfügbaren Aspell-Wörterbücher installiert, führt Git-Gui sogar eine Rechtschreibprüfung durch. Hat der Entwickler eine Quellcodedatei geändert, muss er die Ansicht in Git-Gui neu einlesen – eigenständig erkennt das Tool keine Änderungen.

Über entsprechende Menüpunkte dürfen Anwender neue Branches erzeugen, umbenennen, löschen oder lokal zusammenführen. Darüber hinaus beherrscht Git-Gui das Fetching und Pushing aus und in externe Repositories. Nicht zuletzt bindet das Tool bei Bedarf externe Werkzeuge ein, wobei Git-Gui nur jeweils einen vom Nutzer vorgegebenen Kommandozeilen-Befehl starten kann.

Gitahead

Von Haus aus weniger gut in Git integriert ist Gitahead [3], an dem im Wesentlichen der Entwickler Jason Haslam arbeitet. Die Software steht unter der MIT-Lizenz, die aktuelle Version 2.5.3 ließ sich im Test unter Ubuntu 18.04 problemlos installieren. Interessierte finden sie allerdings nicht im Paketmanager, sondern sie wartet auf Github [5]. Bei dem Paket mit der Endung ».sh« handelt es sich um ein Skript, das der Anwender über »chmod u+x GitAhead-2.5.3.sh« ausführbar macht und anschließend über »./GitAhead-2.5.3.sh« startet. Der Befehl entpackt die in einem Archiv enthaltene Software in einem Unterordner. Der Anwender startet sie über die darin liegende Datei »GitAhead«.

Kooperation

Gitahead kooperiert mit einer Reihe von gängigen Git-Anbietern, zu denen Github, Gitlab, Beanstalk und Bitbucket zählen (Abbildung 4). Bei diesen meldet sich der Nutzer an, für den Test ergänzte der Autor ein Quellcode-Archiv auf Github über »Add GitHub account«.

Abbildung 4: Vier externe Dienste kann die freie Software Gitahead einbinden.

Die Dokumentation zur Software fällt eher spärlich aus. Wer folglich Fragen zu ihr hat, soll sich mit dem Tag »[gitahead]« auf Stack Overflow [6] melden, was aber bisher offenbar noch niemand getan hat. Vermutlich verstehen die meisten Git-Nutzer ohnehin intuitiv, wie die Anwendung funktioniert, und brauchen daher keine helfende Hand. Dass Leute Gitahead tatsächlich verwenden, zeigt sich an den offenen Issues auf Github.

Im linken Bereich präsentiert die Software die entfernten, die geöffneten und die kürzlich genutzten Repositories. Lokal vorgenommene Änderungen lassen sich über den Menüpunkt »Remote | Push« ins entfernte Repository schieben. Wer ein neues Repository anlegen möchte, klickt auf »File | Initialize New Repository« und weist dann einen lokalen Speicherplatz für das Repository zu.

Über »File | New File« lassen sich in einem recht schlichten Editor neue Dateien anlegen und über »File | Save« in dem eben angelegten Repository speichern. Eingecheckt sind sie dann noch nicht: Ein Klick auf das neue Repository zeigt »Uncommited Changes«. Im rechten oberen Bereich erzeugt der Entwickler eine Commit Message und klickt dann auf »Stage All« und »Commit« , um alle Änderungen lokal einzuchecken.

Links von der Mitte tauchen die Branches und Commits übereinander in zwei kleineren Fenstern auf. Das obere Fenster listet die Branches auf (oft ist das nur »master«), darunter reihen sich die in ihm enthaltenen Commits auf. Rechts im Fenster erscheinen die Commits im Detail. Ein Klick auf den Stift daneben öffnet sie im eingebauten Editor, in dem sie der Programmierer modifiziert.

Auch das Branchen und Mergen erlaubt die Oberfläche. Um an einem anderen Branch zu arbeiten als »master«, wählt der Entwickler den abzuzweigenden Commit aus und klickt auf »Branch | New Branch«. Will er anschließend im neuen Branch arbeiten, wählt er diesen im »Branches«-Bereich aus und klickt doppelt darauf. Rechts kann er nun auf den Stift klicken, am Code arbeiten und seine Änderungen über [Strg]+[S] oder »File | Save« speichern. Auch diese muss er dann wieder über »Stage All« und »Commit« einchecken.

Sind alle Änderungen in den Branch eingepflegt, montiert ein »Branch | Merge« die beiden Zweige wieder zusammen. Treten Merge-Konflikte auf, zeigt Gitahead im Detailfenster ein Diff an und fragt, welche Änderungen der Entwickler nun übernehmen will – denn möglicherweise gab es inzwischen Änderungen von Dritten an einer Datei.

Die einzelnen Commits zu den Ästen erscheinen unterhalb der Branches. Mehren sich letztere, visualisieren dies die verzweigenden und in unterschiedlichen Farben dargestellten Linien (Abbildung 5). Sie verbinden die Commits und signalisieren dem Entwickler schnell, welche Codeteile temporäre Ausgründungen sind. Wer gerade an einem Branch arbeitet, lässt sich für jeden Commit oben rechts ablesen.

Abbildung 5: Den oft rätselhaften Verästelungen des Codes folgt Gitahead mit Hilfe farbiger Linien.

Ganz unten im Fenster taucht außerdem eine Historie der Commits zu einem Projekt auf. Dort erscheinen auch Fehlermeldungen, wenn sich etwa »master« aufgrund von ungelösten Konflikten nicht auschecken lässt oder wenn Git LFS nicht installiert ist, der Entwickler es aber verwenden möchte.

Um das lokale Repository auf Github zu pushen, meldet sich der Entwickler zunächst dort an und erzeugt dann über den Browser ein neues Repository. Er kopiert den Link dorthin, etwa mit

https://github.com/username/Repository-Name.git

und wählt in Gitahead erst den gewünschten lokalen Branch aus und dann »Repository | Configure Repository«. Ein kleines Fenster öffnet sich. Im Reiter »Remotes« sollte bei einem rein lokalen Quellcodeverzeichnis kein entferntes auftauchen. Das lässt sich aber über das Pluszeichen ergänzen.

Hier fügt der Entwickler zunächst einen Namen ein, etwa »origin/Repository-Name«. In die Zeile darunter gehört der eben gezeigte Link auf Github, das Ganze besiegelt ein Klick auf »Add Remote« und dann »Ok«. Über den Menüpunkt »Remote | Push to« schiebt er sein lokales Repository danach auf Github. Für die anderen Git-Anbieter sollte das Prozedere analog funktionieren. Weitere Commits lassen sich anschließend per Einstellung auch automatisch auf den entfernten Server schieben.

Damit hat Gitahead aber das Ende der Fahnenstange noch nicht erreicht. »Tags« erlauben es, Software mit Versionsnummern zu versehen. Neben einem Merge ist auch ein Rebase möglich, der zum Beispiel einen Feature-Branch an die Spitze des Master-Branch verpflanzt. In der Commit-Übersicht lassen sich Codebeiträge auch wieder rückgängig machen. Dazu genügt ein Rechtsklick auf den Commit-Eintrag und die Auswahl von »Revert« aus dem Kontextmenü.

Drängt die Zeit, will der Entwickler aber seine unfertigen Änderungen noch nicht ins Repository lassen, nutzt er den Menüpunkt »Stash«. Über ihn schiebt er sie zwischenzeitlich ins virtuelle Eisfach, über »Pop Stash« arbeitet er weiter an ihnen. Nicht zuletzt sind Cherry Picks möglich, um nur bestimmte Commits aus der Historie zu picken und in einen anderen Branch zu übernehmen.

Über »Tools | Options« passt der Nutzer zudem noch ein paar Einstellungen an, etwa das Character Encoding, Themes, Fonts und Aktualisierungen. Auch ein externer Editor lässt sich im entsprechenden Tab eintragen, wenn sich dieser im »$PATH« befindet. Um ihn aufzurufen, klickt der Nutzer in der Detailansicht mit der rechten Maustaste auf den Balken oberhalb eines Commits und wählt »Edit in External Editor«.

Wer gewöhnlich in einem anderen Editor arbeitet, speichert die damit erzeugten Dateien einfach im lokalen Git-Repository. Sie tauchen dann als noch nicht abgeschickte Änderung in Gitahead auf.

Gitg

Gnome hat sich bekanntlich funktionaler Sparsamkeit verschrieben, insofern ist es spannend, einen Blick auf Gitg [3] zu werfen. Dabei handelt es sich ebenfalls um ein Git-GUI, das Git-Verzeichnisse visualisiert und sich dabei nahtlos in die Gnome-Oberfläche integrieren soll. Die Software lässt sich in Ubuntu 18.04 über die Paketverwaltung installieren, auf der Platte landet Version 3.26.0.

Code-Repositories heißen in der Gnome-Welt Softwarebestände. Nach dem Start weist Gitg erst mal darauf hin, dass es noch keine solchen findet, bietet aber einen anklickbaren Link zur Suche an. Wer ihm folgt, stößt auf die lokalen Repositories, die Gitg in einer schlichten Übersicht anzeigt.

Im Test gehörte auch das etwas unübersichtliche Test-Repository, das der Autor mit Gitahead angelegt hatte, zu den präsentierten Kandidaten. Ein Klick darauf zeigte, analog zu Gitahead, eine Visualisierung der Commit-Historie mit farbigen Linien an (Abbildung 6).

Abbildung 6: Optisch passt sich Gitg in Gnome ein, dient aber in erster Linie dazu, Git-Repositories zu visualisieren.

Während der Bereich rechts oben die verschiedenen Commits aufreiht, sind deren Inhalte im unteren Fensterbereich zu finden. Wie Gitahead hebt Gitg Änderungen im Diff-Format farbig hervor. Die Spalte ganz links bietet einen kompletten Überblick der Branches in dem ausgewählten Repository.

Wählt er oben rechts per Rechtsklick einen Commit-Eintrag aus, erwarten den Nutzer verschiedene Optionen in einem Kontextmenü. Dazu zählen »Zweig erstellen«, »Tag erstellen«, »Patch erstellen« sowie »Cherry-Pick-Operation nach Branchname«. Tatsächlich lassen sich mit Gitg eigene Branches erzeugen und Branches zusammenführen. Für Letzteres muss der Verfasser unter »Details des Autors« im Konfigurationsmenü der App aber erst mal seine Daten eingeben, sonst protestiert Gitg.

Wer sich für die Option »Tag erstellen« entscheidet, darf eine Versionsnummer für den Commit festlegen, die dann neben diesem Eintrag sowie links unter dem Eintrag »Tags« erscheint. Wählt der Anwender »Patch erstellen«, erzeugt Gitg eine Datei mit der Endung ».patch«, die er zwar nicht bearbeiten, aber zumindest im Quellcodeverzeichnis speichern kann. Ansonsten lassen sich mit Gitg noch weitere lokale Repositories ergänzen und vorhandene klonen.

Fazit

Die mitgelieferten GUIs von Git teilen sich die Arbeit. Während Gitk die Abhängigkeiten zwischen Branches optisch darstellt und Suchfunktionen bietet, um sich durch die Commit-Historie zu wählen, überträgt Git-Gui einige der typischen Git-Kommandos auf eine grafische Oberfläche. Beide wirken allerdings aufgrund des eingesetzten Tcl-Tk-Toolkits etwas angestaubt.

Die deutsch lokalisierte Oberfläche erweist sich zudem als Fluch und Segen zugleich. Einerseits finden sich deutschsprachige Nutzer einfacher zurecht. Kennen sie hingegen schon die gängigen Git-Befehle, wirken die Übersetzungen unter Umständen eher verwirrend. Wer allerdings vor dem Aufruf der Software über »export LANG=en_EN« die passende Umgebungsvariable auf Englisch umstellt, erhält englischsprachige Menü-Einträge.

Gitg visualisiert ähnlich wie Gitk im Wesentlichen die Git-Verzeichnisse grafisch, allerdings im Gewand des Gnome-Desktops. Änderungen an den Dateien vorzunehmen, erlaubt Gitg aber nicht. Warum die Gnome-Entwickler sich nicht dafür entschieden haben, funktional umfangreichere quelloffene GUIs an Gnome anzupassen, bleibt ihr Geheimnis.

Merkwürdig aber war, dass sich die Dateien sogar ändern lassen. Dazu genügte im Test schon ein Rechtsklick auf den Dateinamen im unteren Bereich des GUI. Die Option »Datei öffnen« ruft diese in einem Editor auf. Allerdings: Diese Modifikationen tauchten auch nach dem Speichern im Editor und nach einem Neustart von Gitg nicht im Verzeichnisbrowser auf.

Offenbar indexiert die Software nach dem Start die Dateien in den importierten Git-Verzeichnissen nicht neu, was sie aber für Änderungen unbrauchbar macht. Immerhin punktet Gitg mit deutschen Beschriftungen und behält dabei zugleich viele der gewohnten Bezeichnungen wie Tags und Patch bei.

Das englisch lokalisierte Gitahead hinterließ hingegen einen guten Eindruck und bringt die wichtigsten Git-Features in einer grafischen Anwendung unter. Lediglich auf etwas ausgefeiltere Funktionen müssen Entwickler (bislang) verzichten. So sind laut Issue-Tracker noch keine GPG-signierten Commits möglich. Exotischere Fälle wie »git bisect« unterstützt die Software auch noch nicht. Wünschenswert wäre zudem, dass die Entwickler Gitahead besser in vorhandene Linux-Distributionen integrieren, ein entsprechender Feature Request liegt bereits vor.