Was ist Jujutsu (jj)?

Jujutsu, aufgerufen als jj auf der Kommandozeile, ist eine moderne, Git kompatible Versionskontrolle, die 2026 schnell an Verbreitung gewinnt. Das Tool wurde von Martin von Zweigbergk bei Google gestartet, ist in Rust geschrieben und unter Apache 2.0 Lizenz veroeffentlicht. Google nutzt jj intern, der offizielle Code liegt auf GitHub unter jj-vcs und hat bereits ueber 27.000 Sterne gesammelt.

Der entscheidende Punkt fuer PHP Teams: jj arbeitet direkt auf bestehenden Git Repositories. Es liest und schreibt das gleiche .git Verzeichnis, erzeugt echte Git Commits und kann parallel zu Git genutzt werden. Kollegen im Team muessen nichts aendern, GitLab, GitHub und CI Pipelines funktionieren unveraendert weiter. Wer will, nutzt jj lokal als bessere Oberflaeche auf dem Symfony Projekt, der Rest des Teams bleibt bei git.

Jujutsu entfernt konzeptionell einige bekannte Schmerzpunkte von Git: Es gibt keinen Staging Bereich (kein git add), die Working Copy ist selbst ein Commit, und jede Aktion ist ueber das Operation Log rueckgaengig machbar. Im Vibe Coding Kontext mit KI Agents macht das einen enormen Unterschied, gilt aber auch fuer klassische PHP Projekte mit viel Rebase und Cherry Pick Arbeit.

PHP Projekte leben von sauberer Historie. Composer Updates, Doctrine Migrations, Rector Refactorings und Symfony Major Upgrades erzeugen viele kleine, voneinander abhaengige Commits. Wer regelmaessig mit Interactive Rebase, Squash Merges oder Stacked Pull Requests arbeitet, kennt die Situationen, in denen Git unbequem wird.

Jujutsu loest diese typischen PHP Team Probleme auf mehreren Ebenen:

• Automatische Snapshots: Jeder jj Befehl schreibt die aktuelle Working Copy als Commit weg. Kein git stash verlieren, kein vergessenes git add.
• Operation Log mit Undo: jj op log zeigt jede Operation auf dem Repository, jj op restore macht jede Aktion rueckgaengig. Ein verunglueckter Rebase ist kein Datenverlust mehr.
• First Class Conflicts: Merge Konflikte werden im Commit gespeichert, nicht im Arbeitsbereich. Man kann in Ruhe loesen, andere Aufgaben dazwischenschieben und zurueckkommen.
• Bookmarks statt Branches: Anonyme Arbeitsstraenge ohne Zwang zur fruehen Benennung. Name wird erst gesetzt, wenn klar ist, was gebaut wurde.
• Stacked Changes: Arbeit an drei voneinander abhaengigen Features gleichzeitig, automatisches Rebasen nachgelagerter Commits bei jeder Aenderung an einer Basis.

Fuer Teams, die mit KI Coding Agents wie Claude Code oder Cursor an PHP Codebases arbeiten, ist der Snapshot Mechanismus besonders wertvoll. Agents machen viele, teils experimentelle Aenderungen. Mit jj ist jede Zwischenstufe wiederherstellbar, ohne dass das Team im Hauptrepository etwas merkt.

jj laeuft auf macOS, Linux und Windows. Auf dem Mac ueber Homebrew, auf Linux per Cargo oder paketiert, auf Windows ueber Scoop oder winget. Die Installation beruehrt bestehende Git Konfigurationen nicht.

Im bestehenden Symfony oder Laravel Projekt wird jj colocated eingerichtet. Das bedeutet, jj und git arbeiten parallel im selben Verzeichnis auf der gleichen .git Instanz. Teamkollegen sehen keinen Unterschied.

Ab jetzt kann das Team mit git weiterarbeiten, waehrend man selbst jj Befehle nutzt. Pushes landen als echte Git Commits auf GitLab oder GitHub, Merge Requests funktionieren wie gewohnt. Die NCA Kollegen nutzen genau diesen Weg fuer Sulu CMS, Symfony und Shopware Projekte.

Wer mit Git Interactive Rebase vertraut ist, versteht jj schnell: Vieles, was in Git ein bewusster, oft angstbesetzter Eingriff ist, ist in jj der Normalfall. Die zentralen Unterschiede:

• Kein Staging Bereich: Die Working Copy ist selbst ein Commit. Es gibt kein git add, keine Verwirrung zwischen getrackten und ungetrackten Aenderungen.
• Working Copy als Commit: jj macht bei jedem Befehl einen Snapshot. Dadurch ist der Zustand vor jeder Aktion auffindbar.
• Change ID statt Commit Hash: Jeder Change hat eine stabile ID (z.B. pqomwrlk), die erhalten bleibt, auch wenn der Commit durch Rebase oder Amend umgeschrieben wird. Das vereinfacht die Arbeit mit abhaengigen Changes enorm.
• Automatic Rebase: Wenn ein frueher Commit geaendert wird, werden alle nachgelagerten Commits automatisch rebasiert. Kein manuelles git rebase --interactive mehr fuer Fixups.
• Operation Log: jj op log zeigt die komplette Historie aller Aktionen auf dem Repository, jj op restore bringt alles zurueck. Ein Sicherheitsnetz, das Git in dieser Form nicht hat.
• Bookmarks statt Branches: Bookmarks sind Zeiger auf Changes, die sich bei Rebases mitbewegen. Erst beim Push werden sie zu klassischen Git Branches.

Fuer PHP Teams, die Feature Branches, CI Pipelines und Code Review ueber GitLab oder GitHub fahren, aendert sich im Remote Workflow nichts. Jeder jj push ergibt einen ganz normalen Git Push. Der Gewinn liegt in der lokalen Arbeit.

Der Umstieg ist ueberschaubar. Wer Git kennt, ist nach wenigen Tagen mit jj produktiv. Die folgenden Kommandos decken den Alltag in PHP Projekten ab:

Besonders nuetzlich im PHP Alltag: jj split trennt einen Change in mehrere Teile auf, jj squash fasst Changes zusammen, und jj abandon verwirft einen Change, ohne die Historie zu beschaedigen. Alle diese Aktionen rebasen abhaengige Changes automatisch.

Der produktive Einsatz von Claude Code, Cursor oder anderen Coding Agents in PHP Projekten hat einen wunden Punkt: Die Agents machen viele, kaskadierende Aenderungen, komprimieren ihren Kontext und koennen dabei Arbeit verlieren oder ueberschreiben. Git allein reicht als Sicherheitsnetz nicht aus.

Mit jj laeuft der Agent in einem Netz aus automatischen Snapshots. Der typische Workflow:

• Vor jeder groesseren Agent Session: jj new -m "claude-session: rector migration" setzen.
• Agent arbeiten lassen, Code generieren, Tests laufen.
• Ergebnis nicht gut? jj op restore und an der gleichen Stelle neu starten, ohne manuelles stash oder reset.
• Ergebnis gut? jj squash, beschreiben, Bookmark setzen, pushen.

Der Anthony Panozzo Blog Post aus November 2025 beschreibt genau diesen Pattern: jj wird zum Sicherheitsnetz fuer KI Agents, weil der Snapshot Mechanismus bei jedem Befehl greift. Wer taeglich mit Vibe Coding und PHP arbeitet, bekommt mit jj eine robustere Arbeitsbasis.

Der Charme von jj fuer deutsche Agenturen und PHP Produktteams liegt in der Null Risiko Einfuehrung. Es braucht keine zentrale Entscheidung, keine GitLab Migration, keine CI Anpassung. Einzelne Entwickler koennen jj ausprobieren, Erfahrungen sammeln und die Praxis intern weiterempfehlen. Fuer Teams, die Symfony, Shopware, Sulu CMS oder Laravel Codebases pflegen, bedeutet das: kein technisches Risiko bei gleichzeitig deutlich besserer lokaler Arbeitsqualitaet.

Wichtig fuer den produktiven Einsatz: jj ist noch pre 1.0. Die Syntax entwickelt sich, der Release Takt ist hoch. Fuer Projekte mit strengen Stabilitaetsanforderungen empfiehlt sich, die jj Version im Team zu pinnen und ueber einen zentralen Installationsweg zu verteilen. Die Git Kompatibilitaet garantiert: Selbst wenn jj morgen eingestellt wuerde, bleibt das Repository ein normales Git Repository.

NCA begleitet PHP Teams bei der Einfuehrung moderner Entwickler Tools. Ob Symfony Upgrades, Rector Refactorings, Sulu CMS Projekte oder der Aufbau von Vibe Coding Workflows mit Claude Code: Wir sorgen dafuer, dass das Team produktiv bleibt und die Codebase gesund ist. Kontakt: roland@nevercodealone.de oder +49 176 24747727.

Die wichtigsten Fragen rund um Jujutsu jj fuer PHP Entwickler, Teams und DevOps Verantwortliche im Jahr 2026.