Warum überhaupt einen Blick auf Jujutsu werfen

Teil 1 von 9 einer Serie über das Erlernen von jj im Colocated-Modus.

Git funktioniert. Fünfzehn Jahre später ist das Ökosystem drumherum enorm, und jeder im Team kennt es bereits. Das ist eine hohe Hürde für alles, was beansprucht, es zu ersetzen, und Jujutsu (jj) versucht gar nicht erst, diese Hürde in einem Sprung zu nehmen. Es versucht, auf denselben Git-Repositories aufzusitzen, die alle ohnehin schon haben, sodass die Einführung eine persönliche Entscheidung ist statt einer Team-Migration.

Ein paar Dinge daran sind den Blick schon aus sich heraus wert, unabhängig von jeder philosophischen Vorliebe für ein “besseres” Versionskontrollmodell:

  • Kein Staging-Bereich. Jeder Befehl macht zuerst einen Snapshot des Arbeitsverzeichnisses. Es gibt keinen Moment, in dem git status einen Haufen ungestagter und gestagter Änderungen zeigt und ich mir merken muss, was was ist.
  • History-Bearbeitung ohne Zeremonie. jj edit <commit> lässt mich etwas drei Commits zurück direkt korrigieren, kein git rebase -i, kein Detached HEAD, keine “bitte verlier meine Arbeit nicht”-Angst. Lektion 5 behandelt das vollständig.
  • Ein Operations-Log, breiter als ein Reflog. jj undo macht das Letzte rückgängig, was ich mit dem Repository gemacht habe, was auch immer es war, nicht nur das letzte Ref-Update.
  • Konflikte sind einfach Daten. Ein konfliktbehafteter Rebase hält nicht an und verlangt eine Auflösung, bevor ich irgendetwas anderes tun kann. Er produziert einen Commit, der den Konflikt festhält, und ich kümmere mich darum, wann immer ich will.

Nichts davon erfordert, Git aufzugeben. Der Colocated-Modus, ein einziges Arbeitsverzeichnis, gestützt von sowohl .jj als auch .git, bedeutet, dass die eigentliche Objektdatenbank darunter weiterhin schlichtes Git ist. Jeder Kollege, der nie von jj gehört hat, jede CI-Pipeline, jede Git-GUI funktioniert genau weiter wie zuvor. Das ist die Eigenschaft, die das überhaupt erst ausprobierenswert macht: Der Nachteil einer schlechten Passung liegt nahe null, weil sich an den geteilten, sichtbaren Teilen des Repositories nichts ändert.

Der Plan für diese Serie: Installation, das mentale Modell, wie das Ding darunter tatsächlich gebaut ist, die Terminal-Ausgabe angenehm anzusehen machen, dann der tatsächliche tägliche Workflow und wie er auf dem Weg zu einem Remote auf Git trifft.