GitComet in der Analyse: Rust-GUI als difftool und mergetool für Git
Dieses Projekt rundet „GitComet is fastest open source user interface for GIT workflows. GitComet User Survey We re running this short survey to better understand how people use our Git GUI client in their daily work.“ zu einer praxistauglichen Open-Source-Lösung zusammen, mit wiederverwendbarer Tooling- und Integrationsunterstützung für reale Anwendungsfälle.
Auf einen Blick
- Was ist das?
- Was GitComet v0.2.1 für große Repositories leistet, wie die Einbindung als git difftool über gitcomet setup funktioniert und wo die junge Rust-Anwendung noch Grenzen hat.
- Für wen ist es gedacht?
- GitComet passt zu Entwicklern, die in großen Repositories arbeiten und eine GUI suchen, die sich als git difftool und git mergetool einbinden lässt, ohne die bestehende Git-Konfiguration zu zerstören. Weniger geeignet ist es, wenn man die Professional-Funktionen wie Claude-Code-Integration sofort braucht, denn diese Edition ist noch in Planung und per Warteliste gebunden.
- Darf ich es kommerziell nutzen?
- Ja, unter strengen Bedingungen. AGPL-3.0 ist eine Lizenz mit Netzwerk-Copyleft: Wenn andere eine veränderte Version über ein Netzwerk nutzen, etwa als gehosteten Dienst, müssen Sie ihnen den Quellcode unter derselben Lizenz anbieten.
- Wird es noch gepflegt?
- Ja. Die letzten Commits kamen vor 2 Tagen.
- In welcher Sprache ist es geschrieben?
- Hauptsächlich Rust, laut der Sprachstatistik von GitHub.
Die Antworten beruhen auf den GitHub-Daten des Projekts (zuletzt abgeglichen am 14. September 2026) und auf unserer Analyse. Sie sind keine Rechtsberatung.
TIEFGEHENDE OPEN-SOURCE-ANALYSE
GitComet aus Rust: warum der Fokus auf Repositories wie Chromium liegt
GitComet ist eine Git-GUI in Rust unter der AGPL-3.0, für Linux, Windows und macOS. Das Projekt beschreibt sich selbst als schnellstes Open-Source-Frontend für Git-Workflows, eine Angabe, für die das README keine Messwerte liefert. Die Motivation steht aber konkret im Abschnitt Why GitComet: Die Autoren konnten auf Codebasen in der Größenordnung von Chromium kein Werkzeug finden, das beim Stöbern in großen Repositories und Datei-Diffs reaktionsschnell bleibt.
Der zweite Grundpfeiler ist lokale Datenhaltung. GitComet will Git-Operationen ohne Cloud-Zwischenschicht abwickeln, Remotes, Pull und Push, Staging, Commits, Worktrees, Branching und die komplette Historie inklusive. Mit Stand August 2026 ist das Projekt früh: v0.2.1 ist die aktuelle Version, der Standardbranch heißt dev, und die Community auf GitHub umfasst rund 780 Sterne. Das erklärt auch den Release-Rhythmus, zwischen v0.2.0 und v0.2.1 liegen drei Tage.
gitcomet setup: wie die Einbindung als git difftool abläuft
Der praktischste Teil von GitComet betrifft nicht die GUI, sondern die Rolle als externes Diff- und Merge-Werkzeug. Der Befehl gitcomet setup schreibt die nötigen Git-Config-Einträge global, unter anderem merge.tool auf gitcomet, den mergetool.gitcomet.cmd mit den Platzhaltern BASE, LOCAL, REMOTE und MERGED sowie mergetool.trustExitCode und mergetool.prompt. Mit --local beschränkt man die Änderung auf das aktuelle Repository, mit --dry-run gibt der Befehl die Kommandos vorher aus, ohne etwas zu schreiben.
Das Rückgängigmachen ist mitgedacht. gitcomet uninstall legt alte Nutzerwerte unter gitcomet.backup.* ab und stellt sie nur zurück, solange der Schlüssel noch den von setup geschriebenen Wert trägt. Hat man zwischenzeitlich selbst etwas geändert, bleibt dieser Wert erhalten. Beide Befehle sind laut README idempotent, mehrfaches Ausführen verändert die Konfiguration also nicht weiter. Das ist mehr Sorgfalt, als viele Git-Tools beim Werken an der globalen Config zeigen.
Headless oder GPUI-Fenster: die zwei Modi von gitcomet difftool
GitComet lässt sich in zwei Arten aufrufen. Der headless Modus rechnet nur den Diff- bzw. Merge-Algorithmus durch und ist für CI, Skripte und Umgebungen ohne Display gedacht. Der GUI-Modus öffnet ein interaktives Fenster auf Basis von GPUI. Das setup registriert beide Varianten mit guiDefault=auto, Git wählt also die Oberfläche, wenn ein Display verfügbar ist, und fällt sonst auf headless zurück.
Die Kommandozeile spricht Klartext: gitcomet difftool --local <path> --remote <path> nimmt optionale Labels und Anzeigenamen an, gitcomet mergetool ergänzt --merged und optional --base, was bei add/add-Konflikten entfällt. Fehlen die Parameter, liest das Tool LOCAL, REMOTE, MERGED und BASE aus der Umgebung, so wie Git sie beim Aufruf übergibt. Kompatibilitätshalber versteht GitComet auch die Aufrufformen von KDiff3 und Meld, etwa --L1/--L2/--L3 und --output, sodass ein Wechsel ohne Anpassung von Git-Skripten möglich ist.
GitComet installieren: brew, apt.gitcomet.dev, AUR und emerge
Die Installationspfade sind ungewöhnlich breit für ein junges Projekt. Unter macOS und Linux genügt brew install --cask gitcomet, wobei der Cask auf Linux ein AppImage installiert. Wer keine AppImages starten kann oder will, greift zum APT-Repository: Zwei curl-Befehle legen den Keyring unter /usr/share/keyrings/gitcomet-archive-keyring.gpg und die Quelle in /etc/apt/sources.list.d/gitcomet.sources ab, danach folgt sudo apt install gitcomet. Auf Arch gibt es das AUR-Paket via makepkg -si, auf Gentoo installiert emerge --ask dev-vcs/gitcomet aus dem GURU-Overlay.
Zwei Details sollte man kennen. Erstens verlangt GitComet eine lokale Git-Installation ab Version 2.50, ältere Systeme müssen Git vorab anheben. Zweitens brauchen Tarball- oder Homebrew-Installationen auf Debian, Ubuntu oder WSLg die GUI-Laufzeitbibliotheken separat, das README nennt libxcb1, libxkbcommon0 und libxkbcommon-x11-0. Wer ohnehin baut, nutzt cargo build -p gitcomet --features ui-gpui,gix und startet mit cargo run unter Angabe eines Repository-Pfads.
Themes und Crash-Logs: was GitComet auf der Platte ablegt
Die Optik ist konfigurierbar. Eingebaute Themes sind direkt in die GitComet-Binary einkompiliert, eigene liegen als JSON-Bundles in einem nutzerspezifischen Themes-Verzeichnis, das die Anwendung beim ersten Start anlegt. Schemabeschreibung, Beispiel-Bundles und das Override-Verhalten dokumentiert die Datei docs/themes.md im Repository, nicht mehr das README selbst.
Für die Fehlersuche gibt es einen festen Ablageort für Absturzprotokolle: Unter Linux schreibt GitComet Panic-Logs und Wiederherstellungsdaten nach $XDG_STATE_HOME/gitcomet/crashes/, mit dem Fallback ~/.local/state/gitcomet/crashes/, unter macOS nach ~/Library/Logs/gitcomet/crashes/. Wer nach einem Update der Anwendung oder des Systems auf Schwierigkeiten stößt, schaut dort zuerst nach. Das ist ein kleiner, aber realer Unterschied zu Tools, die Abstürze stillschweigend schlucken.
Editionen bei GitComet: Open Source um 0 Euro, Professional in Planung
Das Modell ist zweiteilig. Die Open-Source-Edition kostet laut README dauerhaft nichts, ist für private und kommerzielle Nutzung frei und deckt den kompletten lokalen Workflow ab, von Multi-Repository-Browsing über Inline- und Side-by-Side-Diffs bis zum 2-Wege- und 3-Wege-Merge-Werkzeug. Die Professional-Edition ist geplant und soll 20 Euro als Early-Adopter-Angebot einmalig kosten. Sie verspricht Anbindungen an Claude Code, Codex und die GitHub CLI, Workflows zur Testabdeckung sowie GitHub- und Azure-DevOps-Integration. Interessierte tragen sich auf gitcomet.dev/#editions in eine Warteliste ein.
Wer bis dahin nur Diffs braucht, kann selbstverständlich bei Meld oder KDiff3 bleiben, beide Aufrufformen versteht GitComet ja direkt. Der Unterschied besteht in der Kombination: idempotentes setup und uninstall für die Git-Config, ein headless Modus für Skripte und der Anspruch, auch bei Repositories in Chromium-Größe flüssig zu bleiben. Die Geschwindigkeitsaussage ist selbst berichtet und im README nicht mit Zahlen belegt, man sollte sie am eigenen Repo nachprüfen. Unter der AGPL-3.0 ist die Weitergabe veränderter Versionen zudem an Bedingungen geknüpft, die für interne Werkzeugdistributionen relevant werden können.
Redaktionelles Fazit
GitComet passt zu Entwicklern, die in großen Repositories arbeiten und eine GUI suchen, die sich als git difftool und git mergetool einbinden lässt, ohne die bestehende Git-Konfiguration zu zerstören. Weniger geeignet ist es, wenn man die Professional-Funktionen wie Claude-Code-Integration sofort braucht, denn diese Edition ist noch in Planung und per Warteliste gebunden. Vor dem Alltagseinsatz sollte man die Git-Version gegen die Grenze 2.50 prüfen, mit gitcomet setup --dry-run die geschriebenen Config-Einträge ansehen und einen Merge-Konflikt einmal im headless und einmal im GUI-Modus durchspielen.
Community-Notizen