Git on livingIT

Bookmarks sind keine Branches, und das ist der Punkt

Thu, 01 Oct 2026 00:00:00 +0000

Bookmarks sind keine Branches, und das ist der Punkt

Teil 8 von 9.

jjs benannte Zeiger “Bookmarks” statt “Branches” zu nennen sah anfangs nach unnötigem Vokabular aus. Ist es nicht. Ein Git-Branch rückt jedes Mal automatisch vor, wenn du committest, während er ausgecheckt ist, das Ref und deine aktuelle Arbeitslinie sind dasselbe, bis du explizit wechselst. Ein jj-Bookmark ist davon entkoppelt: Du kannst mehrere Commits über der letzten Stelle arbeiten, auf die ein Bookmark zeigt, und es bleibt einfach dort, bis du es mit jj bookmark set verschiebst oder indem du den Commit rebasierst, an den es angehängt ist.

Teammitglieder, die jj nie anfassen, müssen nicht wissen, dass es existiert

Thu, 01 Oct 2026 00:00:00 +0000

Teammitglieder, die jj nie anfassen, müssen nicht wissen, dass es existiert

Teil 9 von 9.

Das war die Frage, die vor der Übernahme von all dem für echte Arbeit am meisten zählte: Was passiert, wenn ein PR-Review-Kommentar von jemandem kommt, der schlichtes git verwendet, oder wenn ich selbst aus Gewohnheit auf einen schlichten git-Befehl zurückfalle. Die Antwort stellte sich als der undramatischste Teil der ganzen Serie heraus, nichts Besonderes passiert, weil der Colocated-Modus bedeutet, dass jj dieselbe Git-Objektdatenbank liest und schreibt wie alle anderen. Ein mit git push gepushter Commit und ein mit jj git push gepushter Commit sind am anderen Ende dieselbe Art von Objekt.

History bearbeiten, ohne die Luft anzuhalten

Mon, 28 Sep 2026 00:00:00 +0000

History bearbeiten, ohne die Luft anzuhalten

Teil 7 von 9.

Die drei Züge, die diese Lektion behandelt, neue Arbeit beginnen, bestehende Arbeit bearbeiten, neue Arbeit von einem Punkt in der Vergangenheit aus beginnen, bilden Dinge ab, die ich in Git ohnehin ständig getan habe. Der Unterschied ist, wie sehr ich mich früher darauf gefasst gemacht habe.

jj new, das die aktuelle Arbeitskopie abschließt und eine leere öffnet, ist unspektakulär, im Grunde git commit mit entferntem Staging-Schritt. Der, der verändert hat, wie ich arbeite, ist jj edit <change-id>. Etwas zwei Commits zurück zu korrigieren bedeutete früher git rebase -i, edit in der richtigen Zeile auswählen, die Korrektur machen, git rebase --continue und hoffen, dass unterwegs nichts weiter unten in Konflikt geriet. Mit jj verschiebt jj edit einfach die Arbeitskopie auf diesen Commit. Jede Datei, die ich anfasse, ergänzt ihn direkt. Nachfahren werden automatisch rebasiert, sobald jj mir den Graphen das nächste Mal zeigen muss. Kein Detached-HEAD-Zustand, kein mehrstufiger Rebase, den man auf halbem Weg abbrechen muss, wenn ich meine Meinung ändere, jj undo deckt das ab.

jj log dazu bringen, über das Remote zu sprechen

Tue, 22 Sep 2026 00:00:00 +0000

jj log dazu bringen, über das Remote zu sprechen

Teil 6 von 9.

Was mich jj log als Alltagswerkzeug vertrauen ließ statt als Spielerei, war zu sehen, wie der Remote-Zustand ohne zusätzliche Zeremonie darin auftaucht. jj git fetch aktualisiert jjs Sicht auf jedes Remote-Bookmark, und das Standard-Log-Template annotiert Commits bereits mit den Bookmarks, ob lokal, remote oder beides, die auf sie zeigen.

Die Marker zu lesen brauchte einen Moment der Gewöhnung. main main@origin in derselben Zeile bedeutet, dass das lokale und das Remote-Bookmark derzeit übereinstimmen. old-experiment@origin ohne ein bloßes old-experiment bedeutet, dass es ein Bookmark ist, das niemand lokal hat, nur sichtbar, weil es auf dem Remote existiert. Ein Sternchen an einem von beiden bedeutet, dass sie divergiert sind.

jj wie Tokyo Night aussehen lassen

Tue, 22 Sep 2026 00:00:00 +0000

jj wie Tokyo Night aussehen lassen

Teil 5 von 9.

Das ist die am wenigsten essenzielle Lektion der Serie und die, an der ich das meiste unmittelbare Vergnügen hatte. jj liefert keine Theme-Presets, es liefert eine [colors]-Konfigurationstabelle, in der jeder Schlüssel ein Style-Label ist, das an getemplatete Ausgabe angehängt ist (change_id, bookmarks, conflict und so weiter), und der Wert ein Farbname, ein Hex-String oder eine Tabelle für fett, kursiv, unterstrichen. Das ist ein allgemeinerer Mechanismus als ein fester Theme-Schalter, zum Preis, das Theme selbst bauen zu müssen.

Repositories forken mit jj

Mon, 21 Sep 2026 00:00:00 +0000

Repositories forken mit jj

“Fork” ist eines der meistgenutzten Wörter in der täglichen Arbeit mit GitHub, GitLab, Gitea, Forgejo oder Bitbucket - und es existiert weder in git noch in jj. git help kennt keinen fork-Befehl, jj help genauso wenig. Alles, was Forken wie eine natürliche Erweiterung der Versionsverwaltung wirken lässt, ist ein Feature der Hosting-Plattform, aufgesetzt auf ein Werkzeug, das nur Repositories, Commits und Refs kennt - und diese Grenze rührt jj gar nicht erst an. Die Beispiele unten nutzen durchgehend jj, im Colocated Mode.

Wie jj darunter tatsächlich gebaut ist

Sat, 19 Sep 2026 00:00:00 +0000

Wie jj darunter tatsächlich gebaut ist

Teil 4 von 9.

Das mentale Modell aus dem letzten Beitrag (Arbeitskopie als Commit, Change-ID getrennt von der Commit-ID) ist die nach außen sichtbare Geschichte. Nachdem ich jjs eigene Design-Dokumente und den Quellcode-Aufbau etwas länger als unbedingt nötig durchgegangen bin, erklärt die zugrunde liegende Architektur, warum dieses Modell zusammenhält und warum sich der Colocated-Modus nicht anfühlt wie das Betreiben zweier zusammengeklebter Versionskontrollsysteme.

Der Commit-Store ist ein austauschbares Backend, und Git ist eine Implementierung davon. jj definiert seinen eigenen internen Begriff eines Commits, und ein Backend-Trait entscheidet, wie das in Bytes auf der Platte verwandelt wird. Das Git-Backend ist der Standard und dasjenige, das dieser ganze Kurs verwendet; es speichert jjs Commits zufällig als echte Git-Commit-Objekte. Das ist der eigentliche Mechanismus hinter “alles ist darunter immer noch ein normales Git-Repo”, es ist keine nachträglich angeschraubte Übersetzungsschicht, es ist der primäre Speicherpfad.

Das Vokabular, das jj von Git übernimmt, verändert und weglässt

Fri, 18 Sep 2026 00:00:00 +0000

Das Vokabular, das jj von Git übernimmt, verändert und weglässt

Die Falle bei jj ist, dass es mehrere Git-Begriffe für etwas anderes wiederverwendet, statt durchgängig neue zu erfinden. Das ist zu Beginn schlimmer als ein sauberer Schnitt gewesen wäre: Ein wirklich neues Wort zwingt dazu, nachzuschlagen, ein vertrautes lässt einen annehmen, man kenne es schon.

Branch wurde zu Bookmark, und der Unterschied ist nicht kosmetisch. Ein Git-Branch folgt immer seiner Spitze - committest du darauf, rückt er automatisch mit vor. Ein jj-Bookmark tut das nicht; es bleibt dort stehen, wo du es hingesetzt hast, bis du es mit jj bookmark set bewegst. Als ich zum ersten Mal dreimal committete und erwartete, dass mein Feature-Bookmark mitwandert, und feststellte, dass es immer noch auf den ersten Commit zeigte, hörte das auf, eine Namenskuriosität zu sein, und wurde zu einer Tatsache, die ich tatsächlich verinnerlichen musste.

Die Arbeitskopie ist ein Commit

Wed, 16 Sep 2026 00:00:00 +0000

Die Arbeitskopie ist ein Commit, und andere Dinge, die einen Moment brauchten, bis es klick machte

Teil 3 von 9.

Gits mentales Modell hat drei Schichten: Arbeitsverzeichnis, Index (Staging-Bereich) und Commits. Die meiste alltägliche Reibung, die ich mit Git verbinde, git add -p, das Vergessen, eine Datei zu stagen, git status, das überlappende “staged”- und “unstaged”-Abschnitte für dieselbe Datei zeigt, kommt vom Verwalten der Grenze zwischen den ersten beiden.

jj entfernt diese Grenze. Das Arbeitsverzeichnis ist der Inhalt eines echten Commits, adressiert als @. Jeder Befehl macht zuerst einen Snapshot davon. Es gibt kein jj add. Der Wunsch, “manche, aber nicht alle” der aktuellen Änderungen zu committen, wird von jj split erledigt, was ein expliziter Akt am Commit selbst ist statt einer laufenden Nebenverhandlung mit einem Index.

Colocated-Modus

Sun, 13 Sep 2026 00:00:00 +0000

Colocated-Modus: zwei Speicher, ein Verzeichnis

Teil 2 von 9.

Die Installation selbst ist ein Nicht-Ereignis, ein Paketmanager oder ein cargo install, dann eine user.name/user.email-Konfiguration, dieselbe Form wie Gits eigenes Erst-Setup. Der interessante Teil beginnt bei jj git init --colocate.

Führe das innerhalb eines bestehenden Git-Checkouts aus, und es legt ein .jj-Verzeichnis neben .git an, fügt .jj/ zu .git/info/exclude hinzu, damit es nie als untracked auftaucht, und importiert die aktuellen Branches und HEAD als jj-Commits. Nichts in .git wird umgeschrieben. Wenn ich .jj jetzt sofort löschte, wäre das Repository genau das schlichte Git-Repo, das es vorher war, nichts verloren.

Warum überhaupt einen Blick auf Jujutsu werfen

Thu, 10 Sep 2026 00:00:00 +0000

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.