LazyGit - Git-UI für faule Entwickler

 (bwplotka.dev)
12 Punkte von GN⁺ 2025-11-11 | 1 Kommentare | Auf WhatsApp teilen
  • Das terminalbasierte Git-UI-Tool lazygit kombiniert die Einfachheit der Kommandozeile mit der Intuitivität einer grafischen Oberfläche und bietet so eine schnelle und konsistente Arbeitsumgebung
  • Es wurde rund um Konsistenz, Auffindbarkeit und Interaktivität entworfen, sodass selbst Einsteiger es mit grundlegenden Git-Kenntnissen sofort nutzen können
  • Vim-Style-Keybindings und eine klare visuelle Struktur ermöglichen schnelle Navigation und verkürzen wiederkehrende Aufgaben
  • Zeilenbasierte Patches, interaktives Rebase, Cherry-Pick usw. vereinfachen komplexe Git-Aufgaben und steigern die Produktivität
  • Es basiert auf einem in Go geschriebenen Open-Source-TUI-Framework und ist damit auch ein interessantes Beispiel für die UX-Gestaltung anderer Entwickler-Tools

Der Hintergrund der Entstehung von LazyGit

  • Der Autor stieß während eines Neovim-Experiments eher zufällig auf lazygit und entdeckte dabei die Effizienz des Tools
    • Danach stellte er seinen gesamten Git-Workflow auf lazygit um
  • Zuvor nutzte er eine Mischung aus git gui, gitk und CLI, suchte wegen veralteter UI und Instabilität jedoch nach Alternativen
  • lazygit ist einfach, schnell und strukturell mit der CLI kompatibel, was seine Zuverlässigkeit erhöht

Die wichtigsten Merkmale von LazyGit

Konsistenz (Consistency)

  • Die Oberfläche besteht aus mehreren „View-Boxen“ und behält stets dieselbe visuelle Struktur bei
    • Wird die linke Box ausgewählt, ändert sich der Inhalt rechts entsprechend
  • Es verwendet Git-Terminologie und -Abstraktionen unverändert, wodurch die Lernkurve abgeflacht wird
    • Beispiel: Standard-Git-Konzepte wie bisect oder hunk lassen sich ganz natürlich erlernen
  • Durch Vim-Keybindings (h/j/k/l, q, /, y, c, a, f, p, r usw.) ist eine schnelle Bedienung möglich
  • Die Anzahl der Befehle bleibt begrenzt und folgt der Unix-Philosophie: „eine Sache gut machen“

Auffindbarkeit (Discoverability)

  • Direkt beim Start werden sofort die benötigten Informationen angezeigt
    • aktuelles Repository, Branch, Staging-Status, letzte Commits, Stashes, letzter Befehl, Shortcuts usw.
  • Informationen werden ohne visuelle Überlastung präsentiert, was Kontextwechsel minimiert
  • Über den Footer unten oder die Taste ? lassen sich Shortcuts sofort nachsehen
  • Nutzer können ihre aktuelle Position und den Status jederzeit intuitiv erfassen

Interaktivität (Interactivity)

  • Komplexe Git-Aufgaben werden über eine dialogorientierte Oberfläche geführt
    • Beispiel: Beim Pushen gibt es Warnungen zu Upstream-Unterschieden, beim Rebase eine Nachfrage, ob es interaktiv sein soll
  • Bei Rebase, Konfliktlösung und Branch-Wechsel werden automatisch Bestätigungen und nächste Schritte vorgeschlagen
  • Statt pick/drop/squash direkt eingeben zu müssen, lassen sich diese Aktionen per Tastenkombination ausführen
  • Mit minimaler Unterbrechung steigen Vertrauen und Geschwindigkeit der Nutzer

Verbesserter Git-Workflow

  • lazygit führt keinen völlig neuen Workflow ein, sondern macht bestehende Git-Funktionen sicherer und schneller nutzbar
  • Mit der Funktion zur Patch-Auswahl auf Zeilen- und Hunk-Ebene lässt sich Code sehr fein granular wiederherstellen
    • So können nur Teile eines Commits zurückgenommen oder getrennt werden
  • Beispiele für wichtige Kurz-Workflows
    • Bestehenden Commit ändern und pushen: 2 space A P enter
    • Neuen Commit erstellen und pushen: 2 space c <제목> P
    • Branch rebasen: 3 r i ... m c
    • Commit löschen: 4 d
    • Commit aufteilen: 4 enter enter <c-p> n <제목> enter
    • Cherry-Pick: 3 4 C 3 4 V
  • Bei wiederholter Nutzung verinnerlichen sich die Shortcuts ganz natürlich, was die Arbeitsgeschwindigkeit deutlich erhöht

Lehren für die UX von Entwickler-Tools

  • Die Einfachheit, Konsistenz, Auffindbarkeit, sinnvollen Standardwerte und Interaktivität von lazygit sind hervorragende Prinzipien für das Design von Entwickler-Tools
  • Tiefe Konfigurierbarkeit, Erweiterbarkeit und ein Open-Source-Ökosystem für Beiträge werden gesund aufrechterhalten
  • Es basiert auf dem zu 100 % in Go geschriebenen TUI-Framework gocui, das sich auch für die Entwicklung anderer Tools nutzen lässt
  • Es zeigt das Potenzial für neue CLI-/TUI-Tools, die ähnliche UX-Muster anwenden

Fazit

  • lazygit wird nicht nur als einfache Git-UI gesehen, sondern als Best-Practice-Beispiel für Entwicklerproduktivität und UX-Design
  • Auch wenn sich KI-gestützte Funktionen weiterentwickeln, spielt es im Bereich der Versionsverwaltung, in dem Genauigkeit und Zuverlässigkeit entscheidend sind, weiterhin eine zentrale Rolle
  • Das Tool entwickelt sich durch Beiträge und Zusammenarbeit der Open-Source-Community kontinuierlich weiter
  • Jeder kann es nutzen und dazu beitragen und erhält dabei eine schnelle und intuitive Git-Erfahrung

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2025-11-11
Hacker-News-Kommentare

  • Früher mochte ich keyboard-zentrierte Git-TUIs wie magit, neogit und lazygit.
    Inzwischen nutze ich statt Git aber jujutsu (jj).
    Nachdem ich mich an die jj-CLI gewöhnt hatte, habe ich angefangen, jjui zu verwenden.
    Ich muss häufig Commits aufteilen, und dafür ist das Plugin hunk.nvim extrem nützlich.
    Und für die Auflösung von jj conflict ist jj-diffconflicts unschlagbar.
    Mit jj kann ich den Commit-Graphen jetzt ganz natürlich bearbeiten, fast so, als würde ich Codezeilen verschieben.

    • Danke für die vielen Tool-Links. Mich würde interessieren, ob du noch andere Tools kennst, mit denen man Diffs in einer Patch-Serie trennen oder neu zusammensetzen kann.
      Wenn man aus einem älteren Commit unnötige Hunks entfernt, entstehen in späteren Commits oft Kettenkonflikte. Ich frage mich, ob es ein Tool gibt, das so etwas automatisch behandelt.
    • Ich bin auch vollständig von Git auf jj umgestiegen. Allerdings ist die Diff-Ansicht von lazygit übersichtlicher, deshalb nutze ich dafür noch immer lazygit.
      Die nach Dateien getrennte Diff-Darstellung gefällt mir einfach besser, und das ist der einzige Grund.
    • Ich bin ebenfalls dabei, auf jj umzusteigen. Noch nicht in allen Projekten, aber das ist nur eine Frage der Zeit.
      Ich hätte allerdings gern mehr GUI-Tools speziell für jj. Wenn ich mehrere Änderungen auf einmal sehen will, nutze ich gg, aber dort fehlt ein Side-by-Side-Diff.
      Nachdem ich ein Video zu GitButler gesehen habe, dachte ich, es wäre schön, wenn sich eine jj-Oberfläche ähnlich weiterentwickeln würde.
      Eine GUI, in der man Änderungen per Drag-and-Drop verschieben oder interaktiv splitten/rebasen kann, wäre großartig.
    • Das Problem mit Git ist, dass es zu unopinionated ist.
      Jedes Team hat seinen eigenen Git-Flow, und Entwickler verlieren sich entweder in unnötigen Mikrooptimierungen oder scheuen sich davor, es überhaupt richtig zu lernen.
      Dadurch landet man am Ende in einer Struktur, in der jedes Team einen Git-Experten braucht.
      Lieber hätte ich ein Tool, das einfach eine einzige Arbeitsweise erzwingt.

  • Das mag vielleicht komisch klingen, aber von allen Git-UIs, die ich bisher benutzt habe, war SourceTree immer noch die beste.
    Für einfache Aufgaben ist es viel angenehmer als die CLI, und die Ansicht für Dateistatus und Historie ist wirklich hervorragend.
    Auch Stage/Unstage auf Hunk- oder Zeilenebene geht leicht.
    Schade ist nur, dass es keine Linux-Version gibt. Ich habe alle möglichen anderen Tools ausprobiert, komme am Ende aber immer wieder darauf zurück.
    Kürzlich habe ich auch lazygit ausprobiert, und unter den TUIs war das ziemlich gut.

    • Hast du magit ausprobiert? Es basiert auf Emacs und hat zwar eine Lernkurve, ist aber vollständig keyboard-zentriert, und es ist schwer, einen Workflow zu finden, den es nicht unterstützt.
    • Beim Committen war für mich die Commit-Ansicht von Git Extensions am besten.
      Sie aktualisiert sich nicht automatisch und gerät dadurch nicht mit der CLI in Konflikt.
      Git-Extensions-Commit-Dokumentation
    • Ich mag Sublime Merge am liebsten. Es ist schnell, hat eine saubere UI, läuft gut auf allen Plattformen und man bezahlt nur einmal für eine einzelne Lizenz.
    • Ich finde Fork oder Tower viel besser als SourceTree. Hast du vielleicht nur kostenlose Tools ausprobiert?
    • Es gibt kaum eine UI auf der Welt, die ich mehr hasse als SourceTree.
      Ich habe mit zahllosen Bugs und merkwürdigen Problemen Zeit verschwendet. Bitte lasst SourceTree hinter euch.

  • Je mehr ich Git direkt benutze, desto stärker spüre ich die Irrationalität der Git-CLI-Oberfläche.
    Ich verwende seit zwei Jahren jj, und ich glaube nicht, dass ich noch zur Git-CLI zurückkehren kann.
    Ich habe einfach zu oft gesehen, wie Leute wegen Git verwirrt sind und Probleme verursachen, daher empfehle ich lieber, gleich etwas anderes zu benutzen.

    • Ich habe jj auch mehrfach ausprobiert, aber der Workflow fühlt sich für mich nicht natürlich an, deshalb werde ich langsamer.
      Ich teile Änderungen gern direkt im Editor auf und committe sie dann, aber jj hat zu wenig Editor-Integration, wodurch meine Commits am Ende unordentlich werden.

  • Wegen des Namens wird es oft gemieden, aber GitHub Desktop ist ziemlich gut.
    Es funktioniert auch mit Repos außerhalb von GitHub gut, und Commit-Änderungen sowie Cherry-Picks auf Datei- und Zeilenebene sind einfach.
    Komplexere Aktionen sind jeweils erklärt, was besonders für Einsteiger hilfreich ist.
    Bei Merge- oder Graph-Funktionen ist es schwächer, aber trotzdem deutlich besser als die Git-CLI, finde ich.
    Wenn neue Teammitglieder dazukommen, lasse ich sie immer GH Desktop verwenden. Es führt zu weniger Fehlern und schnellerem Verständnis.

    • Ich stimme bei GH Desktop zu. Neue Funktionen kommen zwar langsam, aber dafür mit Bedacht.
      Für Menschen, die sich mit Git nicht sicher fühlen, ist es die beste Wahl.
      Andererseits habe ich zu oft erlebt, wie Junior-Entwickler mit zu viel Selbstvertrauen in Git ein Repo ruiniert haben.
      Deshalb empfehle ich GH Desktop meinem Team sehr nachdrücklich.
    • Das Fehlen von Merge-/Konfliktbehandlung und eines Graphen bei GH Desktop ist für viele wahrscheinlich gerade der Grund, es zu meiden.

  • Viele Git-Nutzer kennen git-absorb nicht.
    Es passt gut zu praktisch jedem Git-Flow und nimmt viel Schmerz aus dem Verteilen gestagter Änderungen auf mehrere Commits.
    Die meisten TUIs haben so eine Funktion nicht.

    • Klingt nützlich, aber ich benutze magit, deshalb gehen Commits und Rebase bei mir ohnehin schnell.
      Rust-basierte Tools mag ich nicht besonders, weil sie zu viele Abhängigkeiten mitbringen.
    • Das ist auch im GNU/Debian-Repo enthalten.
    • Ich habe es ein paar Monate lang benutzt, aber dabei kam es vor, dass Commits falsch gesquasht wurden und das Repo halb durcheinandergeriet.
      Dadurch habe ich das Vertrauen verloren und benutze es nicht mehr. Dass es zu magisch funktioniert, ist für mich eher ein Nachteil.
    • Für mich ist die Klarheit der Historie wichtiger. Die Aufzeichnung nur für hübschere Namen umzuschreiben, halte ich nicht für eine gute Idee.

  • Ich bevorzuge immer noch tig.
    Es hat weniger Funktionen, aber die UI ist schlicht und schnell.
    Ich nutze es hauptsächlich zum inkrementellen Hinzufügen zum Index.

    • Ich verwende tig zum Stagen von Hunks inzwischen auch seit mehr als 15 Jahren.

  • VS Code ist kostenlos, plattformübergreifend und wird ohnehin schon von vielen genutzt.
    Die Git-GUI ist ebenfalls gut, und die üblichen Workflows lassen sich alle damit abdecken.
    Normalerweise nutze ich die CLI, aber wenn ein Projekt ohnehin in VS Code geöffnet ist, ist die GUI oft schneller und intuitiver.

    • Aber ich finde, das Problem ist eben, dass man dafür VS Code selbst benutzen muss.

  • Die Kombination LazyVim + tmux hat meine Art, Git zu benutzen, komplett verändert.
    Ich habe es so eingerichtet, dass beim Drücken von ctrl-g lazygit in einem tmux floating pane im aktuellen Verzeichnis erscheint.
    So kann ich Git-Arbeit sofort erledigen, ohne erst in Neovim zu wechseln oder die UI umzuschalten.
    Für einen terminal-zentrierten Workflow ist das die flexibelste und geschmeidigste Erfahrung.

    • Ich habe vor Kurzem auch tmux display-popup entdeckt.
      Wenn man in ~/.tmux.conf 
      bind-key C-g display-popup -E -d "#{pane_current_path}" -xC -yC -w 80% -h 75% "lazygit"
      hinzufügt, kann man mit ctrl-b ctrl-g ein lazygit-Popup öffnen und es mit q wieder schließen.

  • Ich erledige Git-Arbeit mit Sprachbefehlen + KI. Oder ich finde einfach, dass ctrl-r schon UI genug ist.

  • Das hat noch niemand erwähnt, aber Gitu ist ebenfalls ein ziemlich guter Client.