© Adrian Hughes, 123RF.com

Die Versionsverwaltung Git ist komplex und das zugehörige Kommandozeilentool hat so viele Optionen und Aufrufparameter, dass selbst ausgebuffte Shell-Fans häufig die Manpages bemühen, um etwas nachzuschlagen. Fünf Git-Frontends sichern ihre Hilfe zu.

Zahlreiche Distributionen, die Kernelentwickler und viele andere Open-Source-Projekte setzen auf das Versionsverwaltungssystem Git [1]. Linus Torvalds gründete das Projekt im Frühjahr 2005, und inzwischen läuft Git auf fast allen modernen Unix-Systemen, darunter Linux, Solaris, OS  X und andere BSD-Varianten. Auch für Windows-Systeme gibt es entsprechende Arbeitsumgebungen und Erweiterungen.

Die meisten Linux-Anwender bedienen die Code-Lagerhalle mit dem Kommandozeilentool »git« . Das ist aber so umfangreich und bietet so viele Parameter und Optionen, dass eine gründliche Lektüre der Manpages und ständiges Nachschlagen kaum vermeidbar sind. Die Shellvariante glänzt zudem nicht mit Übersichtlichkeit – wer schon mal mehrere Versionszweige (Branches) entflechten und sich durch ältere Commit-Kommentare wühlen musste, kennt das Problem.

Fünf Grafische Frontends versprechen Abhilfe. In dieser Bitparade treten Git Cola [2], Git Eye [3], Gitg [4], Qgit [5] und Smart Git [6] unter Ubuntu 13.10 in der 64-Bit-Version an. Eine Zusammenfassung der Daten bietet Tabelle 1.

Git Cola

Den Auftakt macht das Python-Programm Git Cola [2]. Das unter der GPLv2 veröffentlichte Git-Frontend ist in den Paketquellen der meisten Distributionen enthalten. Zudem bietet die Projektseite Versionen für OS  X und Windows sowie einen Link zu den Quellen an. Die Tester installierten Version 1.9.3. Git Cola setzt auf Qt 4 für seine Oberfläche.

Nach dem Start präsentiert das Programm ein winziges Fenster, über das Anwender ein lokales Repository öffnen oder ein Git-Projekt klonen. Letzteres öffnet einen Dialog, in den sie die URL eintippen und dann den lokalen Ort wählen. Während des Klonens wirkt das Programm, als wäre es abgestürzt. Ein Fortschrittsbalken oder eine Meldung, dass Git Cola im Hintergrund Daten lädt, fehlt.

Git Cola spricht eine wilde Mischung aus Deutsch und Englisch und bietet für einige Menü-Einträge nicht die etablierten Git-Begriffe an, sondern glänzt mit Kreativität. So heißt »Push« etwa »Versenden« , und »Pull« haben die Macher mit »Veröffentlichen« übersetzt. Git Cola liest die Konfigurationsdateien des Anwenders aus. Im Einstellungsdialog tragen sie Benutzernamen und Mailadresse für das aktuelle Repository sowie für alle Repositories (global) ein. Vorsicht: Das Tool überschrieb im Test ohne Nachfrage vorhandene Dateien ».git/config« und »~/.gitconfig« .

Git Cola wertet die Umgebungsvariablen »$VISUAL« und »$EDITOR« aus, wenn der Nutzer die Felder für den bevorzugten Texteditor in den Einstellungen freilässt. Das klappte allerdings nicht auf allen Testsystemen zuverlässig. Die gewählten Tools für Diff und Merge sowie den Editor trägt das Programm ebenfalls in »~/.gitconfig« ein.

Einige Unterabschnitte des Hauptfensters blendet der Nutzer über das Menü »Tools« ein. Andere Funktionen öffnen neue Unterfenster. Neue, geänderte und im Staging-Bereich (Index) angesiedelte Dateien erscheinen unter »Zustand« (siehe Abbildung 1). Mit einem Doppelklick schiebt der Nutzer einen Eintrag in den Staging-Bereich, wo er auf das Verschicken (Commit) wartet. Ein weiterer Doppelklick entfernt das File wieder aus der Ladezone. Git Cola kann weder neue Dateien erstellen noch vorhandene aus dem Repository löschen, umbenennen oder verschieben. Über das Kontextmenü dürfen Benutzer immerhin Änderungen an einer Datei verwerfen.

Abbildung 1: Das Hauptfenster von Git Cola ist in mehrere Bereiche unterteilt, von denen jeder eine andere Aufgabe übernimmt. Über Schaltflächen erreichen Anwender die wichtigsten »git«-Kommandos.

Koffeinsüchtig?

»Übersicht« zeigt alle im Projekt vorhandenen Dateien an und ermöglicht den Vergleich mit anderen Versionen. Die eigentliche Gegenüberstellung übernimmt »git« selbst. Wer die Versionshistorie abruft, der öffnet das im Einstellungsdialog unter »History Browser« eingetragene Tool. In der Voreinstellung ist das Gitk, das zu Git selbst gehört. Fehlermeldungen und andere Ausgaben landen im Hauptfenster von Git Cola.

Das Python-Programm packt auf Wunsch Tar.gz-Archive des Quellcods und exportiert Patches. Die Suche versteht reguläre Ausdrücke. Geänderte Dateien können Benutzer stashen, also vorübergehend sichern. Tags zum Kennzeichnen bestimmter Codeversionen tackert das Frontend nur an den Anfang oder das Ende eines anderen Zweigs.

Git Cola bereitet die Branches optisch auf (siehe Abbildung 2). Im Gegensatz zur Konkurrenz zeigt das Tool dabei nicht die Commit-Texte direkt im Diagramm an, sondern lagert sie in eine separate Liste aus. Möchte der Anwender wissen, welcher Punkt im Diagramm welchem Commit entspricht, muss er ihn explizit auswählen. Bei größeren Projekten fällt die Zuordnung schwer.

Abbildung 2: Git Cola zeigt die Branches zwar als Diagramm an, die Zuordnung zu einzelnen Commits fällt aber schwer.

Die Anwendung implementiert die Funktionen Push, Pull, Fetch, das Mergen und ein Rebase. Die jeweiligen Dialoge sind allerdings recht karg und umständlich zu bedienen. Ein Merge benötigt beispielsweise mehrere Mausklicks, um die korrekten Zweige auszusuchen. Wer zu einem anderen Branch wechseln möchte, der muss den genauen Namen kennen und in ein Feld tippen – das die Eingabe immerhin automatisch vervollständigt.

Git Eye

Der zweite Kandidat stammt aus der kalifornischen Softwareschmiede Collabnet. Git Eye [3] steht unter einer proprietären Lizenz. Anwender dürfen laut Endbenutzervertrag das Java-Programm auch für kommerzielle Zwecke kostenlos nutzen. Nach 30 Tagen verlangt es eine Registrierung beim Anbieter, die gleichzeitig zu einem Account bei Team Forge [7] oder Cloud Forge [8] führt. Auf der Homepage stehen gepackte Binaries für Linux, OS  X und Windows zur Verfügung (jeweils 32 und 64  Bit). Git Eye basiert auf der Eclipse-Umgebung, die ein JRE ab Version 1.6 voraussetzt.

Das Hauptmenü der getesteten Version 1.5.0 erschien auf dem Testrechner übrigens nicht und das Menü »Edit« präsentierte nur eine leere Fläche. Die meisten Aktionen riefen die Tester daher über das Kontextmenü auf. Per Knopfdruck erzeugen Anwender neue Repositories oder klonen vorhandene. Ein Assistent fragt die notwendigen Informationen ab. Git Eye bietet fertige Dialoge für die erwähnten Dienste Team Forge und Cloud Forge sowie Github [9] und Gerrit [10]. In geöffneten Repositories speichert das Frontend eine Projektdatei namens ».project« , in der es seine eigenen Einstellungen zwischenlagert. In der Voreinstellung fügt das Tool diese Datei den Ausnahmen in ».gitignore« hinzu.

Dateien, Verzeichnisse und Branches zeigt Git Eye in einer Baumansicht am linken Rand. Sie blendet grundsätzlich immer alle vorhandenen Dateien ein; deren Status liest der Anwender am Symbol ab. So markiert ein kleines Fragezeichen alle noch nicht hinzugefügten Dateien. Es ist nicht möglich, die Darstellung zu filtern oder zu sortieren. Für beide Aufgaben wechselt der Anwender rechts zum Reiter »Git Files« (siehe Abbildung 3). Hier findet er weitere Funktionen für einen Commit, unter anderem einen Editor für angehängte Nachrichten und den Staging-Bereich.

Abbildung 3: Git Eye fasst in dem Register »Git Files« die Funktionen für einen Commit zusammen.

Um einen Commit auszuführen, tragen Benutzer einen Kommentar ein und betätigen den gleichnamigen Button. Git Eye berücksichtigt ausschließlich die Dateien im Index. Um diesem neue Files hinzuzufügen, selektieren Benutzer sie in der Projektansicht und wählen aus dem Kontextmenü die Aktion aus. Alternativ hilft ihnen auch hier ein Assistent.

Textdateien öffnet das Java-Programm in einem eigenen Editor. Auf Wunsch startet es aber auch den systemweit oder vom Anwender vorgegebenen Texteditor. Dem Arbeitsverzeichnis neu hinzugefügte Dateien erkennt das Git-Frontend erst nach einer Aktualisierung der Projektansicht. Benutzer dürfen Dateien ausschließen (»untrack« ), als »unchanged« definieren oder sie komplett aus dem Repository entfernen. Es ist nicht möglich, Files zu verschieben.

Einige Reiter des Hauptfensters blenden automatisch ein Diff der ausgewählten Datei ein. Dazu greift Git Eye auf das Kommandozeilentool »diff« zurück. Wem das zu karg ist, der ruft aus dem Kontextmenü eine Ansicht der Unterschiede auf, die einen neuen Reiter öffnet und dort die Änderungen zwischen zwei Versionen grafisch hervorhebt.

Augen auf!

»History« führt wie zu erwarten alle bisherigen Commits auf und zeichnet ein Diagramm (siehe Abbildung 4). Über Filter und eine Suchfunktion schränken Anwender die Auswahl ein. Sie erzeugen hier ebenfalls neue Branches und vergeben Tags. Zweige dürfen sie zusammenführen und löschen. Darüber hinaus kann Git Eye ein Rebase ausführen. Einzelne Commits öffnen Nutzer gezielt per Doppelklick in einer eigenen Ansicht, die allerdings noch weniger Informationen präsentiert als die History.

Abbildung 4: Die History bereitet alle Informationen auf, die das Git-Logfile hergibt.

Benutzer dürfen in Git Eye Commits zurücknehmen (»revert« ), allerdings nicht nachträglich Kommentare verändern. Push, Fetch und Pull rufen sie über die Projektansicht auf, den Check-out finden sie ebenfalls im Kontextmenü der rechten Maustaste. Zwischenstände lassen sich stashen; die Funktion erreichen Nutzer, wenn sie auf den Namen in der Projektansicht rechts-klicken. Konflikte erkennt die Software zwar, markiert aber nur die betroffenen Dateien und unterbreitet keine Lösungsvorschläge. Unbestätigte lokale Änderungen setzen Anwender jederzeit zurück.

Git Eye berücksichtigt sowohl die Datei »~/.gitconfig« als auch die Repository-Konfigurationen ».git/config« und ».gitignore« . Letztgenannter fügen Anwender bequem Dateien über das Kontextmenü hinzu. Die globale Einrichtung beeinflussen sie über die Git-Eye-Einstellungen. Wer mag, der hinterlegt dort eigene Shellkommandos und erreicht diese später ebenfalls über das Kontextmenü. Das Java-Programm erstellt nicht nur Patches, sondern kann sie auch lesen und anwenden.

Die Entwickler haben dem Tool eine einfache Aufgabenverwaltung spendiert – grundsätzlich eine gute Idee, könnte man automatisierte Aktionen definieren und beispielsweise am Ende jedes Arbeitstags einen Commit durchführen. Da ein solches Feature fehlt, wirkt der eingebaute Taskmanager relativ überflüssig und bietet nicht mehr Funktionen als ein Terminkalender. Gut gefiel den Testern allerdings, dass sie Git Eye via Hudson [10] und Jenkins [11] an einen Buildserver anbinden konnten.

Gitg

Das unter der GPLv2 stehende Gitg [4] gehört zum Gnome-Projekt und liegt daher allen gängigen Distributionen bei. Die Tester schauten sich die Variante 0.2.7 aus Ubuntu 13.10 an. Nach dem Start öffnen Anwender über das Menü »Datei« ein lokales Repository (siehe Abbildung 5). Die Arbeit mit entfernten Quellen ist möglich, allerdings ist die Einrichtung nicht ganz intuitiv. Nutzer navigieren dazu »Datei | Repository Properties« an, klicken auf »Hinzufügen« , vergeben einen Namen (ohne den der Zugriff nicht gelingt) und tragen die Adresse ein. Gitg holt die Daten anschließend vom Server, Nutzer erreichen das Repository über »Zweig auswählen« .

Abbildung 5: Gitg ist zwar übersichtlich und visualisiert die Branches und Commits, dafür bietet das Gnome-Tool nur wenige Funktionen.

Im Hauptfenster erscheint eine Liste mit den bisherigen Commits. Branches zeichnet das Tool als Diagramm ein. Über die rechte Maustaste versehen Anwender einen Commit mit Tags, erzeugen neue Zweige, generieren Patches oder verschieben den Commit in einen anderen Branch. Drei Reiter am unteren Rand liefern Informationen zum markierten Commit, unter anderem die ID und die enthaltenen Dateien. Der Klick auf ein File zeigt die Änderungen. Gitg greift dazu auf »diff« zurück und färbt die Ausgabe ein.

Kaum beweglich

Die Programmeinstellungen versprechen mit einem externen Diff-Tool zusammenzuarbeiten, allerdings fehlt eine Möglichkeit, dieses einzutragen. Die globalen Git-Einstellungen aus »~/.gitconfig« nimmt die Gnome-Anwendung allerdings zur Kenntnis, sodass Benutzer dort ihre Vorlieben eintragen. Im Gitg-Einrichtungsdialog dürfen sie lediglich ihren Namen und ihre Mailadresse der globalen Konfiguration anpassen. Die Werte für Repositories (».git/config« ) scheint Gitg zumindest in den Commit-Meldungen zu verwenden; es fehlt allerdings jede Möglichkeit, diese im Programm zu bearbeiten.

Gitg bietet einen internen Editor oder eine Verknüpfung zu einem externen Tool. Anwender arbeiten in ihrem bevorzugten Texteditor und lesen das Repository über »Ansicht | Aktualisieren« neu ein. Zum Löschen oder Verschieben von Dateien wechseln sie auf die Shell und bemühen »git« . Den aktuellen Zustand des lokalen Repository fasst Gitg auf einem eigenen Tab zusammen (siehe Abbildung 6).

Abbildung 6: Auf dem Reiter »Einspielen« bereiten Nutzer den Commit vor. Der Regler rechts blendet mehr oder weniger Zeilen der Diff-Ausgabe ein.

Die neuen und veränderten Dateien erscheinen zunächst unter »Nicht bereitgestellt« . Ein Symbol vor dem Filenamen zeigt an, ob es sich um etwas Neues oder Modifiziertes handelt. Über das Kontextmenü fügen Benutzer Dateien dem Staging-Bereich hinzu. Ins Eingabefeld »Einspielmeldung« schreiben sie ihre Commit-Nachricht ein. Die Schaltfläche »Einspielen« schließt den Vorgang ab. Benutzer dürfen lediglich den zuletzt vorgenommenen Commit revidieren.

Qgit

Auch die andere große Desktopumgebung hat ihr eigenes Git-Frontend. Die KDE-Entwickler schicken Qgit [5] ins Rennen, das unter der GPLv2 steht und auf Qt 4 setzt. Mit Version 2.4 hat das Team um Cristian Tibirna und Chris OBryan die Weiterentwicklung übernommen und setzt die Arbeit von Marco Costalba fort.

Da die älteren Varianten nach wie vor in einigen Distributions-Repositories und vor allem auf Sourceforge kursieren, sollten Anwender bei der Installation unbedingt auf die Versionsnummer achten. Die Tester haben sich die aktuelle 2.5-Ausgabe unter Ubuntu angesehen.

Das Hauptfenster gibt sich übersichtlich (siehe Abbildung 7). Lokale Repositories benennt der Nutzer beim Aufruf oder öffnet sie aus dem Datei-Auswahldialog. Über einen kleinen Trick ist es möglich, entfernte Repositories zu klonen. Dazu definieren Anwender im Menü »Actions« ein eigenes Kommando und tragen dort beispielsweise den Befehl »git clone« gefolgt von einer URL ein.

Abbildung 7: Qgit zeigt im oberen Bereich eine Liste der letzten Commits. Die einzelnen Branches visualisiert die KDE-Anwendung als Diagramm. Benutzer schalten über Reiter zwischen Logfile und Diff-Output um.

Zum Bearbeiten von Dateien bemühen Nutzer einen externen Editor. Das Hauptfenster zeigt eine Liste der letzten Commits, die Branches visualisiert Qgit als Diagramm. Über das Kontextmenü der rechten Maustaste erstellt der Anwender Tags oder einen neuen Zweig. Auf Wunsch erzeugt das KDE-Programm Patches und spielt vorhandene ein.

Informationen über den gerade selektierten Commit erscheinen im unteren Teil. Der Reiter »Diff« zeigt alle Unterschiede zum vorherigen Commit, wobei Qgit ebenfalls die »diff« -Ausgaben präsentiert und sie einfärbt. Wer mag, arbeitet mit einem externen Diff-Tool zusammen und konfiguriert dies in den Programmeinstellungen. Qgit liest die globalen und lokalen Konfigurationen ein.

Qgit punktet mit verschiedenen Ansichtsmodi und Tabs (siehe Abbildung 8). Anwender blättern hier durch die vorhandenen Versionen. Die Commit-ID erscheint in einem eigenen Eingabefeld rechts oben in der Ecke. Das Feld dient gleichzeitig zur Suche: Alle Commits mit der hier eingetippten Zeichenfolge hebt Qgit in der Liste fett hervor.

Abbildung 8: Qgit zeigt die Versionen der Datei »AUTHORS.txt« an, die links im Verzeichnisbaum ausgewählt ist. Per Mausklick blättern Benutzer durch die einzelnen Varianten.

Daneben gibt es eine normale Suchfunktion. Für Patches darf der Nutzer sogar reguläre Ausdrücke verwenden. Die Ergebnisse hebt das KDE-Tool auf Wunsch farblich hervor. Qgit kann zudem die Liste mit den Commits auf die Anzeige der Resultate beschränken.

Beim Commit steht ein Assistent zur Seite. Benutzer hinterlegen eine Commit-Nachricht und wählen dann die gewünschten Dateien zum Übertragen aus. Die Liste führt nur alle neu hinzugekommenen und veränderten Files auf. Qgit berücksichtigt die Ausnahmen aus ».gitignore« . Jeweils den letzten Commit dürfen Anwender über die Schaltfläche »Amend« verändern.

Smart Git

Das Git-Frontend der Firma Syntevo GmbH aus Freilassing heißt Smart Git [6]. Für private Zwecke ist das Programm gratis. Eine Lizenz für den kommerziellen Einsatz schlägt mit rund 75 Euro zu Buche; Support kostet extra (zirka 19 Euro pro Jahr). Im Test trat Version 5.0.5 an. Das Java-Programm, ein Handbuch und Howtos stehen auf der Homepage für Linux, OS  X und Windows bereit.

Smart Git benötigt ein JRE in Version 1.6 oder neuer. Nach dem ersten Start fragt ein Assistent Eckdaten ab. Neben Git- kann das Programm auch Mercurial-Repositories verwalten. Darüber hinaus bietet es direkte Schnittstellen zu Github [9], Assembla [13], Beanstalk [14], Bitbucket [15], Codebase [16] und Unfuddle [17]. Eine kleine Falle gibt es beim Öffnen von lokalen Repositories: Wer hier aus Versehen ein leeres Verzeichnis auswählt, der erzeugt dort automatisch ein neues Repository.

Das Hauptfenster punktet mit einer klaren Aufteilung und Buttons für alle wichtigen Aufgaben (siehe Abbildung 9). Links oben sind alle Repositories verzeichnet, rechts daneben die enthaltenen Dateien. Zu jedem File listet das Programm den Status auf. Eine Filterfunktion schränkt die Aufstellung ein und blendet zum Beispiel nur die geänderten oder all jene Dateien ein, die mit »read« beginnen. Das zugehörige Eingabefeld versteht zwar keine regulären Ausdrücke, aber die Platzhalter »*« und »?« . Die Inhalte der Files durchsucht Smart Git nicht.

Abbildung 9: Das Smart-Git-Programmfenster benötigt viel Platz. Gut gefällt, dass die englischen Git-Kommandos bequem per Schaltflächen erreichbar sind.

Für die ausgewählte Datei zeigt die Anwendung mittig die Unterschiede zur vorherigen Version an. Alternativ stellt es die »HEAD« -Version dem Index gegenüber. Pfiffig: Über eine Tastenkombination oder das Menü springen Benutzer direkt zu den modifizierten Stellen. Diese nützliche Funktion bietet Smart Git auch in den Unterfenstern, in denen es einen Vergleich zwischen zwei Versionen anstellt. Die Branches und Tags präsentiert das Tool in einer Baumstruktur.

Aufgeweckt

Smart Git liest die Werte aus der globalen Konfiguration »~/.gitconfig« . Einige der Angaben dürfen Anwender in den Programmeinstellungen überschreiben. Die Datei ».gitignore« berücksichtigt das Programm und fügt ihr auch neue Einträge hinzu. Benutzer wählen die gewünschte Datei aus, rufen den Menüpunkt auf, ändern gegebenenfalls den vorgeschlagenen regulären Ausdruck oder nicken diesen ab.

Neue Files erzeugen Anwender mit einem externen Werkzeug und laden danach die Ansicht in Smart Git neu. Über das Kontextmenü einer Datei öffnen sie diese in einem Texteditor ihrer Wahl. Ein Doppelklick ruft ein weiteres Fenster auf, das den Inhalt mit der vorherigen Version vergleicht. Die integrierte Suchfunktion assistiert dabei, kennt aber ebenfalls keine regulären Ausdrücke. Den alten Zustand der Datei stellt ein Mausklick wieder her.

Alle Files, die für einen Commit infrage kommen, selektiert eine Tastenkombination in einem Rutsch. Funktionen zum Entfernen aus dem Repository (»remove« ) und zum vollständigen Löschen (»delete« ) sind ebenfalls dabei. Das Programm besitzt zudem einen Indexeditor, mit dem Anwender den Inhalt einer Datei direkt im Staging-Bereich verändern.

Beim Commit assistiert das Frontend. Im Dialog tragen Benutzer einen Kommentar ein und prüfen die Dateien noch einmal. Genau wie die anderen Testkandidaten scheitert Smart Git, wenn es darum geht, den Commit zu signieren. Den letzten Commit nimmt das Tool auf Wunsch zurück. Für die Übergabe startet Smart Git das Kommandozeilentool »git« , dessen Ausgaben im Hauptfenster erscheinen.

Schriftführer

Vielfältig ist das Programm auch bei der Auswertung der Logs. Für die History und die Protokolle bietet Smart Git eine eigene Ansicht (siehe Abbildung 10). In der Mitte zeigt sie alle Commits, links schalten Nutzer die Branches, entfernte Zweige und Tags dazu. Ein Filter schränkt die Ausgabe ein. Hilfreich ist die Möglichkeit, Commits, die sich vereinigen lassen, farblich hervorzuheben.

Abbildung 10: Die Log-Ansicht von Smart Git liefert Informationen über den ausgewählten Commit, etwa die beteiligten Dateien, den Autor und die Commit-ID.

In der Log-Ansicht dürfen Anwender Branches anlegen, zusammenführen, löschen und tracken. Außerdem nimmt Smart Git Reverts vor und enthält sogar eine Rebase-Funktion, hilft also dabei, Commits aufzuteilen und die Stücke neu zusammenzusetzen. Tags dürfen Anwender anlegen, umbenennen und löschen. Das Programm beherrscht Stashing, kann aber keine Patches erstellen. Lokale Änderungen nehmen Nutzer mit einem Check-out zurück.

Alles im Wandel

Eines haben alle Kandidaten gemeinsam: Ohne ein solides Grundwissen zu Versionsverwaltungen allgemein und Git im Speziellen dürften Benutzer keine Freude an ihnen haben. An Git Cola stören die zahlreichen Fenster. Viele Informationen sind erst dann sichtbar, wenn der Anwender sie explizit anfordert. Git Eye versteckt alle wichtigen Optionen in uneinheitlichen Kontextmenüs. Pluspunkte gibt es für den großen Funktionsumfang sowie Anbindungen an Github und die Collabnet-Dienste.

Die Tools der Desktopumgebungen Gitg und Qgit dienen im Wesentlichen dazu, sich schnell einen Überblick über die Zweige in einem Projekt zu verschaffen. Für alle anderen Aktionen müssen Benutzer auf die Shell wechseln. Smart Git überzeugt mit seinem Funktionsumfang und einigen pfiffigen Features. Das Java-Tool ist der Testsieger und empfiehlt sich allen, die mit einer proprietären Lizenz leben können.