Evans Jujutsu-Tutorial

• Ein Tutorial, das so aufgebaut ist, dass Nutzer mit Git-Erfahrung das einfache und zugleich leistungsstarke Versionsverwaltungssystem Jujutsu (jj) kompakt erlernen können
• Für Leser, die vor dem Lernen wissen möchten, warum sie Jujutsu nutzen sollten, wird ein separater Einführungsartikel zu Jujutsu angeboten
• Es verweist außerdem auf Alternativen passend zum Kenntnisstand der Leser, darunter ein dialogisch aufgebautes Einsteigerhandbuch, detaillierte offizielle Dokumentation und Materialien für Einsteiger ohne Erfahrung mit Versionsverwaltung
• Evan Martin hat den Text selbst verfasst, um Themenauswahl, Auslassungen und Reihenfolge sorgfältig festzulegen
• Beim Schreiben des Haupttexts wurde keine KI verwendet; erst nach Fertigstellung des größten Teils wurde KI nur zur Fehlerprüfung eingesetzt

---

Zielgruppe und Lernpfad

• Jujutsu ist ein einfaches und zugleich leistungsstarkes Versionsverwaltungssystem und wird im Tutorial im Folgenden als jj bezeichnet
• Es bietet einen kompakten Lernfluss, der sich auf das Wesentliche konzentriert und sich an Leser richtet, die mit Git vertraut sind
• Wer direkt einsteigen möchte, kann zu Tutorial starten wechseln; wer zuerst die Gründe für den Einstieg nachvollziehen möchte, kann den Einführungsartikel zu Jujutsu lesen

Alternative Materialien je nach Leser

• Falls der Ansatz dieses Tutorials nicht passt, können je nach Erfahrungsniveau und Vorlieben folgende Materialien gewählt werden
  • Steve's Jujutsu tutorial: das am stärksten empfohlene Einstiegsmaterial, dialogisch aufgebaut
  • Jujutsu documentation: bietet ein offizielles Tutorial, das von Anfang an mehr Details behandelt
  • Jujutsu for Everyone: richtet sich an Leser ohne vorherige Erfahrung mit Versionsverwaltung

Eigenständige Erstellung und Umfang des KI-Einsatzes

• Der gesamte Text wurde von Evan Martin selbst geschrieben; welche Inhalte aufgenommen oder ausgelassen werden und in welcher Reihenfolge sie angeordnet sind, wurde sorgfältig von einem Menschen entschieden
• Für die Erstellung des Haupttexts wurde keine KI verwendet; sie kam erst nach dem Schreiben des größten Teils ausschließlich zur Fehlerprüfung zum Einsatz

[GN⁺]

Kommentare auf Lobste.rs

• Um ehrlich zu sein und meinen Ruf aufs Spiel zu setzen: Ich habe jj ungefähr eine Woche lang ausprobiert, bin am Ende aber wieder dazu übergegangen, ein LLM um Hilfe zu bitten, um den Schmerz beim direkten Umgang mit Git zu verringern, und hatte auch nicht das Gefühl, dass es meinen bisherigen Workflow ausreichend ersetzt
  Normalerweise nutze ich nur Dinge wie git checkout, git add, git commit und git push; die in Werbetexten erwähnten Probleme mit Index, Stash, verschiedenen Arten von Reset, laufenden Rebases und inkonsistentem Undo begegnen mir kaum, und Monorepos nutze ich auch selten
  Ich frage mich, wer die Hauptzielgruppe von Jujutsu ist und wie lange es gedauert hat, bis man jj souverän nutzen konnte; beim nächsten Mal möchte ich mindestens so viel Zeit investieren

  • Mich würde interessieren, bei welchen konkreten Aufgaben du dir von einem LLM helfen lässt
    Auch ich vermeide in Git eher alles außer den Basisaufgaben: Statt nach einem Stash den Branch zu wechseln, habe ich das Repository an einem anderen Ort erneut geklont; statt nur die relevanten Änderungen herauszupicken und zu committen, habe ich mit git add --all alles committet oder Änderungen im Editor zurückgesetzt, dann committet und sie anschließend wieder angewendet
    Durch sieben Jahre Mercurial im Job hatte ich zwar einen Hintergrund, der den Umstieg auf jj erleichtert hat, aber inzwischen sind das Umplatzieren von Commits und das Verwalten mehrerer Änderungen so einfach geworden, dass ich auch komplexe Aufgaben aktiv angehe, die ich früher instinktiv umgangen hätte
  • Die Perspektive hängt davon ab, wofür man ein Versionskontrollsystem (VCS) verwendet
    Wenn man linear entwickelten Code nur gelegentlich als Snapshot festhält, reichen diese Befehle aus; ein vollwertiges VCS kann dann überdimensioniert sein, und Dropbox könnte schon genügen
    Für mich ist ein VCS ein Werkzeug zum Aufbau einer Erzählung, das zeigt, wie ich über den Code und seine Schichten nachgedacht habe; die Hauptleser sind Kolleginnen und Kollegen, die Nebenleserin ist mein Ich in zehn Jahren. jj macht es möglich, das mit deutlich weniger Reibung zu handhaben
  • Es ist völlig in Ordnung, ein LLM um Hilfe zu bitten; ich habe das auch so gemacht, bis ich die nötigen Grundbefehle gelernt hatte
    Um ein Fundament bei Begriffen und Funktionen zu bekommen, habe ich einige Anleitungen von Anfang bis Ende gelesen und jj ein paar Tage lang konsequent in privaten Projekten genutzt; danach beherrschte ich die Grundaufgaben ziemlich gut, und auch mein Blick auf VCS hat sich verändert
    Wenn ich ein Refactoring oder ein größeres Feature entwickle, implementiere ich zuerst bis zum Endziel und zerlege es dann in kleine Änderungen, die leicht zu reviewen sind und deren Begründung jeweils klar ist, etwa „alle eslint-Warnungen beheben“, „Refactoring zum Freilegen einer Funktion“, „Aufrufstelle A auf die neue Funktion umstellen“, „neues Feature hinzufügen“. jj split ist dafür perfekt, und allein diese Funktion ist Grund genug, jj zu verwenden
    Dagegen ist git stash schwer zu handhaben, sobald es mehrere Stashes gibt, und hat viele gefährliche Usability-Fallen, bei denen man bei Konflikten gespeicherten Code verlieren kann. Auch PR-Feedback in einen weiter unten liegenden Commit einzubauen und dann die darüberliegenden Commits oder PRs zu rebasen, ist besonders bei gestapelten PRs fast ein Albtraum: Es gibt keine Fortschrittsanzeige, und es ist schwer, zwischendurch anzuhalten oder den Stack wieder aufzubauen. Deshalb nutze ich für die Verwaltung gestapelter PRs weiterhin Graphite
  • Der größte Vorteil, den ich aus jj gezogen habe, ist die Art, wie es Rebases behandelt
    Ein Doktorand der Organischen Chemie hatte einen Branch für seine Paper-Arbeit vier Jahre lang ohne Merge oder Rebase entwickelt und lag vor der Disputation Tausende Commits hinter main; nun musste er gemergt werden. Da fast jeder Commit Konflikte verursachte, hätte das mit Git ein bis zwei Wochen gedauert. Wenn am dritten Tag ein dringender Bug hereinkam, musste man den Rebase abbrechen, den Bug fixen und wieder von vorn anfangen; und wenn man nach drei Wochen fertig war, musste man erneut rebasen, um auf den aktuellen Stand von main zu kommen
    In jj sind Merge-Konflikte First-Class-Objekte, sodass man sie lösen kann, wenn man Zeit hat; selbst wenn man zwischendurch zu einem neuen Commit wechselt, um einen dringenden Bug zu beheben, verliert man den Fortschritt nicht. Einen Rebase, der in Git eine Woche gedauert hätte, konnte ich an einem Tag abschließen; einmal fand ich 200 aufeinanderfolgende Commits, deren Zusammenführen überhaupt nichts änderte, und konnte eine Arbeit, bei der ich zwei Tage lang Zehntausende Zeilen Konflikte bearbeitet hatte, in weniger als einer Minute komplett verwerfen. Selbst während eines Rebases kann man main aktualisieren und den Arbeits-Branch auf das neueste main verschieben

• Für jemanden wie mich, der an Git so gewöhnt ist, dass ich nur gelegentlich Befehle nachschlage, war dieser Artikel der erste Einführungstext zu Jujutsu, der mich wirklich interessiert hat
  Frühere Texte begannen meist mit „Man kann der schrecklichen Git-Kommandozeile entkommen“. Obwohl ich die Eigenheiten von Git und die Schwierigkeiten anderer verstehe, ließ mich diese Formulierung Jujutsu als etwas betrachten, das mit mir nichts zu tun hat, wie Liebesromane oder Beef Vindaloo

  • Der Grund, warum es schwer ist, den Spaß an jj zu erklären, liegt darin, dass implizite Eigenschaften, von denen man annahm, jedes VCS müsse sie haben, in Wirklichkeit gar nicht selbstverständlich sind, und dass atomare Operationen viel einfacher sind
    Weil es schwer ist, gute Werbeslogans dafür zu finden, läuft die Erklärung am Ende vollständig auf „Es ist nicht Git“ hinaus; auch ich kann es nicht wirklich gut erklären
  • In Git kann man die hier genannten Probleme mit der GUI Sublime Merge und ein paar benutzerdefinierten Befehlen fast vollständig lösen
    Anders als andere Git-GUIs folgt sie den tatsächlichen Git-Befehlen so weit wie möglich, ersetzt nur die schwer verständliche Syntax durch Menüs und Buttons und versteckt die zu den jeweiligen Aktionen gehörenden Befehle nicht, sondern protokolliert sie in der Statusleiste. Wenn Sublime JJ erscheint, werde ich sofort wechseln
  • Die Formulierung, die mich dazu gebracht hat, jj ausprobieren zu wollen, war: Git, das sich immer im Zustand eines interaktiven Rebases befindet