Jujutsu für alle

• Dieses Dokument ist ein Einsteiger-Tutorial, das Jujutsu (VCS) in einer schrittweisen Level-Struktur vermittelt, sodass man auch ohne Git-Erfahrung folgen kann
• Es setzt die Nutzung des Terminals voraus, behandelt aber auch die Grundlagen des Terminals; wichtige Befehle werden vor allem für Linux/macOS erklärt, Windows-Nutzern wird WSL empfohlen
• Der Lernablauf ist so aufgebaut, dass in Level 1–3 Grundlagen, Zusammenarbeit und Problemlösung gefestigt und in den höheren Leveln auf History-Rewriting und fortgeschrittene Workflows ausgeweitet werden
• Damit man bei einem durcheinandergeratenen Zustand während des Tutorials weitermachen kann, wird mit einem reset-Skript eine reproduzierbare Lernumgebung bereitgestellt, die zum Startpunkt jedes Kapitels zurücksetzt
• Warum Jujutsu statt Git: Als Gründe werden Git-Kompatibilität, geringere Lernhürde und fortgeschrittene Funktionalität genannt; die Inhalte werden fortlaufend für Jujutsu 0.32 aktualisiert

---

Einführung (Introduction)

• Dieses Tutorial ist Einführungsmaterial für Nutzer, die Jujutsu zum ersten Mal verwenden
• Es bietet einsteigerorientierte Inhalte als Ausgleich dafür, dass bestehende Jujutsu-Materialien sich vor allem auf den Wechsel erfahrener Git-Nutzer konzentrieren
• Die Nutzung des Terminals ist grundlegend; es gibt ein Kapitel zu grundlegender Terminal-Bedienung, und Windows-Nutzern wird die Verwendung von WSL empfohlen

So liest man dieses Tutorial (How to read this tutorial)

• Die Inhalte sind in Leveln aufgebaut; nach jedem Level soll man praktisch üben und dann erst zum nächsten Level weitergehen
• Wenn das Ziel Zusammenarbeit ist, wird empfohlen, Level 1 und 2 direkt nacheinander zu absolvieren
• Überblick über die Level
  • Level 1: Liefert das minimale Start-Set für die persönliche Arbeit; geeignet etwa für Studierende, die Aufgaben alleine verwalten
  • Level 2: Das minimale Set für Zusammenarbeit; nötig für studentische Teamprojekte und Entwickler in der Praxis
  • Level 3: Grundlagen der Problemlösung wie Konfliktbehebung und Wiederherstellung; entspricht etwa dem durchschnittlichen Erfahrungsstand von Entwicklern
  • Level 4: Aufbau einer sauberen Historie durch History-Rewriting; nötig, um in manchen Projekten Qualitätsstandards zu erfüllen
  • Level 5: Produktivitäts-Booster, fortgeschrittene Workflows, seltene CLI-Themen und Theorie, die Jujutsu-Master-Stufe
  • Level 6: Situationsbezogene Themen wie Tags, Submodule und Workspaces; bei Bedarf als Referenz empfohlen

Tastenkürzel (Keyboard shortcuts)

• Mit den linken und rechten Pfeiltasten kann man zwischen Kapiteln navigieren
• Mit S oder / kann man im Buch suchen
• Mit ? wird die Hilfe angezeigt, mit Esc wieder ausgeblendet

Fortschritt zurücksetzen (Reset your progress)

• Da der Zustand des Beispiel-Repositorys mit dem nächsten Kapitel verknüpft ist, kann ein verlorener Zustand den weiteren Fortschritt blockieren
• Um das zu lösen, gibt es ein reset.sh-Skript, das den Zustand auf den Startpunkt eines Kapitels zurücksetzt
• Zu Beginn jedes Kapitels steht der genaue Reset-Befehl, sodass sich der Zustand per Copy-and-paste reproduzieren lässt
• Es wird empfohlen, den Inhalt des Skripts vor der Ausführung zu prüfen; praktisch handelt es sich nur um eine einfache Sammlung manueller Befehle
• Wichtige Eigenschaften des Skripts
  • Mit JJ_CONFIG=/dev/null wird der Einfluss von Benutzereinstellungen unterbunden
  • Es erstellt Beispiel-Repositories, richtet colocate Git-Integration ein, setzt Benutzerinformationen und bildet fortlaufende Szenarien wie Commit/Push/Fetch/Rebase nach
  • Es ist so verzweigt, dass es bei Übergabe eines Kapitel-Schlüsselworts an der entsprechenden Stelle erfolgreich beendet wird

Auf dem neuesten Stand bleiben (Stay up to date)

• Sowohl das Tutorial als auch Jujutsu entwickeln sich kontinuierlich weiter; über ein Abo der Releases des Tutorial-Repositorys kann man Hinweise auf größere Änderungen erhalten
• Das Tutorial gibt an, auf dem Stand von Jujutsu 0.32 (August 2025) aktuell zu sein
• Auf GitHub gibt es Hinweise zum Einrichten von Update-Benachrichtigungen über Watch → Custom → Releases

Wozu Versionsverwaltung nötig ist (What is version control and why use it?)

• Sie ist nicht nur für Software gedacht, sondern eignet sich auch für schrittweises Arbeitsmanagement bei Dingen wie Dokumenterstellung mit Typst
• Sie ermöglicht die Rückkehr zu früheren Zuständen und unterstützt sicheres gleichzeitiges Arbeiten mehrerer Personen
• Wenn man im Vergleich zu gewöhnlichen Backups oder kollaborativen Editoren präzisere Kontrollwerkzeuge braucht, ist Jujutsu passend

Warum Jujutsu? (Why Jujutsu instead of Git?)

• Git-Kompatibilität: verlustfreie Interoperabilität mit bestehenden Git-Repositories; die meisten Git-Integrationswerkzeuge können weiterhin genutzt werden
• Leichtere Erlernbarkeit: Im Vergleich zur komplexen und wenig intuitiven UI von Git bietet Jujutsu dieselben Funktionen mit geringerer Komplexität
• Stärkere Funktionalität: Unabhängig von der leichten Erlernbarkeit bietet es viele Power-User-Funktionen und sorgt so für erweiterbare Workflows
• Nachteile und Überlegungen
  • In Gesprächen gibt es den Aufwand der konzeptionellen Zuordnung zu einer von Git-Begriffen geprägten Kultur; das lässt sich möglicherweise durch Überzeugungsarbeit im Team abmildern
  • Da Jujutsu noch relativ neu ist, fehlen in manchen Fällen einige Git-Funktionen; falls nötig, kann man direkt auf Git zurückfallen
  • Die CLI befindet sich noch im Stabilisierungsprozess, daher können sich einige Befehle ändern; empfohlen wird, die Releases des Tutorials zu abonnieren, um Änderungen zu verfolgen

Lernfortschritt (Completed & Next)

• Derzeit ist es vor allem auf Level 1–3 ausgerichtet, damit man den praktischen Aufgabenfluss (Installation → Initialisierung → Log/Commit → Remote/Push/Klonen → Branch/Merge → Rebase → Navigation → Rückgängig machen/Wiederherstellung → Konfliktlösung → Aufräumen) verinnerlicht
• Für höhere Level wird eine schrittweise Vertiefungsstrategie vorgeschlagen, bei der zusätzlich Rewriting, fortgeschrittene Workflows und seltene Themen gelernt werden

[GN⁺]

Hacker-News-Kommentare

• Ich habe gefühlt schon Dutzende Lobeshymnen auf jj gesehen. Dieses Tutorial ist ähnlich, aber inzwischen habe ich genug über die Vorteile gelesen und interessiere mich mehr für die Nachteile und Unannehmlichkeiten. Als ich jj ausprobiert habe, gab es Vor- und Nachteile. Ich nutze oft einen Workflow, bei dem ich Branches mit Kollegen teile und weiter Commits darauf staple, aber jj war dabei umständlicher als git, weil es keine benannten Branches hat (auch mit dem tug-Alias). Der Abschnitt „Tracking remote bookmarks“ im Tutorial wirkt auf mich ebenfalls immer noch umständlich. Ein weiterer Punkt, der mich gestört hat: jj kann keinen leichten Clone wie git clone --filter=blob:none, und ich frage mich, ob das inzwischen behoben wurde

  • jj hat benannte Branches, sie heißen dort nur „bookmarks“. Wenn man ein Remote-Bookmark verfolgt, wird das Lokale mit jj git fetch mit dem Remote synchronisiert

  • Eines der Dinge, die mir Probleme gemacht haben, war, dass jj manchmal scheinbar zufällig meine Änderungen verloren hat. Ich habe in Cursor gearbeitet und das Repo nicht mit jj mutiert (nur Dinge wie jj status und jj log), aber später waren meine Änderungen manchmal weg, und gelegentlich erschien auch die Meldung "stale workspace". Ich weiß nicht, ob das an der IDE oder an einem riesigen Monorepo lag, aber es war wirklich schmerzhaft. Trotzdem gefällt mir die Flexibilität von jj ziemlich gut

  • Unter https://github.com/jj-vcs/jj/discussions/3549 gibt es eine Diskussion darüber, den tug-Workflow etwas einfacher zu machen

  • Es stimmt nicht, dass jj keine benannten Branches hat. Man muss sie nur manuell angeben, etwa mit jj branch set -r@ XYZ, was etwas umständlich ist, aber nur einmal beim Push nötig wird. Oder man verschiebt den Branch mit jj git push --named XYZ=@

  • Dass jj keinen leichten Clone (git clone --filter=blob:none) unterstützt, ist weiterhin ungelöst

• Es heißt, „Jujutsu ist mächtiger als Git“, aber es wird nicht konkret erklärt, inwiefern es mächtiger ist, daher frage ich mich, warum man es überhaupt benutzen sollte. Das wirkt wie bloße Rhetorik

  • Ich bin der Autor des Tutorials. Da sich der Text an Einsteiger richtet, war ein detaillierter Vergleich mit Git nicht passend. Die Komplexität der Git-UI wird oft mit ihrer „Mächtigkeit“ gerechtfertigt, daher wollte ich den Lesern nur mitgeben, dass sie bei Jujutsu nicht auf Funktionen verzichten, nur weil es leichter zu lernen ist

  • Zum Beispiel: Man erstellt vom Main-Branch aus einen neuen Branch und plant, ihn später als PR einzureichen. Dann stapelt man mehrere Commits und merkt anschließend, dass Commit 1 geändert werden muss. Dann bearbeitet man Commit 1 einfach, speichert, und alle anderen Commits werden automatisch auf den neuesten Stand umgebased. Auch nach der PR kann man, wenn man Commit 3 ändern will, einfach genau diesen Commit bearbeiten und pushen. So etwas direkt mit Git zu machen, ist wirklich schwierig. Meine Kollegen lieben PRs, die in mehrere Commits aufgeteilt sind

  • Ich sehe das ähnlich. Insgesamt finde ich Git-UIs eher schwach, daher wäre ich bereit, jj bis zu einem gewissen Grad zu vertrauen und zu nutzen. Aber eine konkrete Demonstration, warum es einfacher, mächtiger oder bequemer ist, wäre besser gewesen

  • Ein Beispiel: Merge-Konflikte kann man als einzelnes Element registrieren und später bearbeiten: https://jj-vcs.github.io/jj/latest/conflicts/

• Ich habe JJ kürzlich wieder ausprobiert, und es ist deutlich besser geworden, sodass ich es jetzt gern nutze. Als ich es anfangs ausprobiert habe, hatte es noch viele raue Kanten, aber ich sehe JJ als Teil einer neuen Welle großartiger Tooling-Neuerscheinungen. Ich habe dazu auch im Blog geschrieben: https://pdx.su/blog/2025-08-13-the-quiet-software-tooling-renaissance/

  • Guter Artikel. Ich finde auch, dass die Messlatte für Entwickler-Tooling in den letzten Jahren wirklich stark gestiegen ist. Rust ist ebenfalls Teil dieser Veränderung

  • Schön zu sehen, dass du mise ebenfalls nutzt und magst. mise, jj (und das absolut großartige jjui-TUI) sowie uv für Python sind alle revolutionär. Ich finde solche Tools wirklich schön

  • Ich würde hier unbedingt auch nushell hinzufügen

  • Bun steht ebenfalls an der Spitze dieser Tooling-Revolution

• Großartige Arbeit! Ich nutze seit fast fünf Monaten ausschließlich Jujutsu und habe git damit komplett ersetzt. Tatsächlich habe ich Git in dieser Zeit 52-mal ausgeführt (davon 11-mal mit --help), Jujutsu aber ganze 582-mal. Man muss seinen Workflow nicht anpassen; Jujutsu ist flexibel genug, um fast jeden Workflow zu unterstützen. Selbst wenn man es wie git nutzt, kann man Commits und Branches frei verschieben (ohne stashen zu müssen), einfach rebasen (für Git-Profis vielleicht vertraut, aber ich bin sehr dankbar, dass es direkt ohne die Git-Tools von VSCode geht), und man kann sich auf die Arbeit konzentrieren, ohne die nervigen Teile eines VCS. Wichtig ist: Die Arbeitshistorie bleibt wie bisher auch im Git-Repo erhalten, also ist es mit anderen Git-Tools kompatibel. Meine Kollegen müssen ihr VCS also nicht wechseln, nur weil ich etwas anderes nutze. Bei Tags, Submodulen und LFS gibt es noch kleinere Schwächen, aber ausprobieren lohnt sich auf jeden Fall

  • Mich würde interessieren, was das jj-Äquivalent zu git branch --set-upstream-to ist

  • Wenn man jjui nutzt, wird man die jj-Befehle künftig fast nicht mehr anfassen. Wirklich erstaunlich

• Jujutsu ist wirklich gut. Ich habe es vor ein paar Monaten ausprobiert und ein paar Artikel dazu geschrieben (diesen hier), und seitdem nutze ich es weiter. Insgesamt ist es eine sehr „konsistente“ Erfahrung. Ich war eigentlich jemand, der auch mit git problemlos arbeiten konnte, aber bei jj basiert alles auf ein paar Grundprinzipien, und man kann sie beliebig kombinieren, um auch komplexe Änderungen an der Historie leicht vorzunehmen. Früher habe ich stark mit „stash“ gearbeitet, aber jj ist dank automatischer Änderungsverfolgung, freiem Verschieben von Änderungen und Ähnlichem viel angenehmer als git. Auch Rebase und Konfliktlösung sind deutlich besser (vor allem bei einem stash-artigen Workflow). Klare Empfehlung, und der Umstiegsaufwand ist sehr gering

• Persönlich mag ich den Ansatz nicht besonders, eine neue Schicht über git zu legen. Ich verstehe, dass es schwer ist, die Hegemonie von git zu durchbrechen, aber auf einer völlig neuen Grundlage aufzubauen wäre meiner Meinung nach viel mächtiger und freier

• Ich habe jj ungefähr einen Monat lang verwendet und bin dann wegen eines bestimmten Projekts bei der Arbeit wieder zu git zurückgekehrt. jj hat mir wirklich gefallen, aber mehr auch nicht. Doch nur wenige Stunden nach der Rückkehr zu git habe ich die Bequemlichkeit von jj enorm vermisst: https://blog.nawaz.org/posts/2025/Aug/the-jujutsu-effect/

  • Mich würde interessieren, was genau mit „mehr auch nicht“ gemeint ist

  • Man erkennt den wahren Wert oft erst, wenn man etwas verloren hat

• Ich würde gern mehr zum Thema „Jutustsu for Git experts“ lesen. Zum Beispiel frage ich mich, ob das Committen von Konflikten mein git rerere kaputtmachen würde, oder ob es in jj einen bequemen Weg gibt, ein zweistufiges Patch-Set umzusetzen, da ich in git gern mit git add -p nur Teile eines Patches stage. Ich möchte beschädigte Timestamps oder sinnlose Rebuilds im Build-System vermeiden

  • Ich antworte aus der Sicht des in jj am weitesten verbreiteten Workflows (dem „squash workflow“). Man ändert frei im Working Directory des obersten Commits, und wenn man „stagen“ will, squash't man die Änderungen nach unten in den darunterliegenden Commit (entweder alles oder mit -i nur Teile). Mit squash --into kann man auch einen anderen Commit angeben und gezielt dorthin squashen

  • 1. jj verwendet kein git rerere, daher geht die Frage etwas am Thema vorbei. 2. @ ist der Workspace, und @- ist der Commit, an dem du arbeitest. Mit jj squash -i kannst du interaktiv Teile des gewünschten Diff wieder nach @ zurückholen

  • Obwohl ich der Aussage „Die Unterscheidung zwischen Stage und Unstage ist unnötig“ zustimme, finde ich die Meinung „Aber nur die guten Teile eines Patches zu stagen ist wirklich großartig“ interessant. Mit einer Kombination aus git worktree, git diff, vi und git apply kann man ohne Staging etwas Ähnliches erreichen, aber es ist wirklich umständlich. Selbst in mercurial 7.1 gibt es noch kein interaktives Add, sodass außer Worktree-Tricksereien kaum Alternativen bleiben

• In letzter Zeit habe ich öfter von Jujutsu gelesen, mich aber nicht mit konkreten Workflows beschäftigt. Mich interessiert, ob Jujutsu gegenüber Emacs Magit besondere Vorteile hat. Die meisten Git-UIs, die ich bisher genutzt habe, fand ich schwach, aber Magit hat meine Produktivität mit git stark erhöht und mir auch die „Magie“ von git vermittelt. Will Jujutsu mit dieser Erfahrung konkurrieren, oder ist es eher als Alternative zu den bestehenden Git-UIs gedacht, die tatsächlich schwach sind?

  • Jujutsu ist nicht einfach nur eine Git-UI, und als Git-UI ist es eher schwach (etwa wegen mangelnder Unterstützung für Tags, Submodule usw.). Es ist ein völlig neues VCS, das git als Backend verwendet. Wenn git gegenüber SVN „cheap branches“ gebracht hat, dann bringt JJ „cheap rebases“. Konflikte stoppen nicht den gesamten Arbeitsfluss, und Rebase sowie das Organisieren von Commit-Strukturen sind wirklich bequem. Wenn du schon einmal mit stacked diffs gearbeitet hast, wird es dir vertraut vorkommen, und stacked-diff-PRs sind in jj fast ohne Aufwand möglich

  • Wenn du schon viel mit Magit arbeitest, werden dir die Grundkonzepte von jj wahrscheinlich ebenfalls gefallen. jj ermöglicht Commit-Akrobatik, die man vorher für unmöglich gehalten hätte (zum Beispiel die zwei Blätter eines 5-Wege-Octopus-Merge mit ungelösten Konflikten zu rebasen). Das ist übrigens eine Technik, die ich entwickelt habe und „Mega Merge“ nenne. Magit und jj haben gewisse Ähnlichkeiten; ich denke, die „Git-Magie“ entsteht in Wahrheit durch die „Designsprache“ des Tools. Git ist nur die physische Storage-Schicht für Magit und jj, während Algorithmik, UX und Konzepte große Unterschiede ausmachen. Magit-Nutzer sind von jj meist weniger schockiert, aber fortgeschrittene Git-CLI-Nutzer wechseln besonders leicht zu jj und werden oft zu starken Fürsprechern. Sie verstehen besser als alle anderen, wie mächtig ein Tool sein kann, das Commit-Graphen manipuliert. Zur Einordnung: Ich bin einer der Maintainer von jj und halte es für ein sehr gut gemachtes Werkzeug. Probiere es ruhig ein paar Tage lang einmal ohne Magit aus

  • Hier sind ein paar passende Links. Ein Artikel, der den Megamerge-Workflow gut erklärt: https://v5.chriskrycho.com/journal/jujutsu-megamerges-and-jj-absorb/, https://ofcr.se/jujutsu-merge-workflow, und das erstklassige TUI, das die jj-CLI umhüllt: https://github.com/idursun/jjui

  • Mich interessiert, was das „zentrale Konzept“ von Jujutsu ist. Angesichts dessen, dass Git der Industriestandard ist, fehlt mir noch ein wirklich überzeugender Grund, Jujutsu zu verwenden. Die Konzepte finde ich spannend, aber aus Marketing-Sicht würde eine klarere Botschaft wahrscheinlich die Verbreitung fördern. Das größte Problem von Git ist meiner Meinung nach seine extreme Unfreundlichkeit gegenüber Außenstehenden (Terminologie, schlechte Auffindbarkeit, Mangel an GUI-Frontends usw.), daher sehe ich viel Potenzial für ein einsteigerfreundliches VCS

  • Ich bin von Magit zu jujutsu gewechselt. Der größte Unterschied ist, dass das Stapeln von PRs viel einfacher geworden ist und ich mir angewöhnt habe, Änderungen in kleinere Einheiten aufzuteilen, wodurch meine Schwelle dafür, was „es wert ist, verschickt zu werden“, gestiegen ist. Insgesamt war es eine positive Erfahrung, aber wenn Magit schon sehr gut für dich funktioniert, gibt es keinen besonderen Killer-Vorteil. Dank https://github.com/bolivier/jj-mode.el kann man jj in Emacs aber gut nutzen

• Fand ich interessant. Obwohl ich viel online unterwegs bin, habe ich Jujutsu zum ersten Mal überhaupt kennengelernt. Mir gefällt die Idee, git als Backend zu nutzen und trotzdem ein besseres VCS anzubieten. Einer der Gründe ist, dass Backups und gemeinsames Arbeiten weiterhin über Github-Gitlab möglich bleiben. Fossil oder Bitkeeper sind ebenfalls attraktiv, aber nicht „genug“ besser als git, um dessen Netzwerkeffekt zu überwinden. Ich werde Jujutsu ein wenig ausprobieren. Ob ich dabei bleibe, weiß ich nicht, aber ich hoffe, dass es besser ist, als ich denke