git-parsec — von der Worktree-Erstellung bis zum PR-Merge mit nur einem Ticket

Ein CLI-Tool, das einen parallelen Entwicklungs-Workflow auf Basis von Git worktree automatisiert.

Gelöstes Problem

Wenn man an mehreren Tickets gleichzeitig arbeitet, ohne zwischen Branches zu wechseln, ist git worktree eine gute Wahl.
Für den praktischen Einsatz im Arbeitsalltag gibt es jedoch viele wiederkehrende Schritte:

• Worktree erstellen und Branch benennen → mit parsec start PROJ-123 in einer einzigen Zeile
• Pushen, PR erstellen und Ticket-Link anhängen → mit parsec ship PROJ-123 in einer einzigen Zeile
• CI prüfen, mergen und Worktree aufräumen → mit parsec merge PROJ-123 in einer einzigen Zeile

Wiederkehrende Aufgaben, die man jedes Mal manuell erledigen musste, werden jeweils auf einen einzigen Befehl reduziert.

Kern-Workflow

parsec start PROJ-123       # worktree + 브랜치 + Jira 티켓 연동  
# ... 코딩 ...  
parsec ship PROJ-123        # push → PR 생성 (티켓 제목/링크 자동 포함)  
parsec ci PROJ-123          # CI 상태 테이블 출력  
parsec merge PROJ-123       # CI 대기 → squash 머지 → worktree 자동 정리  

Hauptfunktionen

Tracker-Integration

• Jira / GitHub Issues — Ticket-Titel automatisch übernehmen, Statusübergänge, Board-Ansicht, Inbox
• parsec ticket — Ticket-Details im Terminal anzeigen
• parsec board — Jira-Sprint-Board per CLI anzeigen

Worktree-Verwaltung

• Shell-Integration — mit parsec switch automatisch per cd zwischen Worktrees wechseln
• Stacked PRs — mit der Option --on PR-Ketten aufbauen, mit stack sync gesammelt rebasen
• Undo — auch versehentlich aufgeräumte Worktrees mit einem Befehl wiederherstellen

Automatisierung

• Release — Tag + Merge + GitHub Release + Changelog automatisch erstellen
• Human / JSON / Quiet-Ausgabemodi — einfache Integration in CI-Skripte
• 27 Subcommands — start, list, status, ship, merge, ci, diff, sync, adopt, rename usw.

Installation

cargo install git-parsec  

Alternativ können macOS- / Linux-Binärdateien unter GitHub Releases heruntergeladen werden.

Nützlich für

• alle, die gleichzeitig an mehreren Tickets arbeiten (worktree-basierte parallele Entwicklung)
• alle, die die wiederkehrenden Aufgaben zwischen Jira und Git satthaben
• alle, die in einem Monorepo die Kosten des Kontextwechsels reduzieren möchten
• alle, die AI-Agenten (z. B. Claude Code) eine isolierte Arbeitsumgebung geben möchten

Links

• GitHub: https://github.com/erishforG/git-parsec
• Installation: cargo install git-parsec

Es ist in Rust geschrieben, leichtgewichtig und kann direkt auf bestehende Git-Repositories angewendet werden.
Feedback oder Fragen sind willkommen!

[puddingman220]

Ich bin kürzlich durch einen Tech-Blog über parallele Worktrees darauf aufmerksam geworden und fand das Thema spannend, war aber enttäuscht, dass man die Implementierungsdetails nicht sehen konnte. Mit diesem Open-Source-Projekt sollte man sich das wirklich einmal genauer ansehen!

Unten ist der Blogbeitrag, den ich gelesen habe.
https://medium.com/ajd-tech/…

[erish2150]

Vielen Dank! Auch der Inhalt Ihres Blogbeitrags ist beim lockeren Durchlesen wirklich hervorragend geschrieben.
Wenn sich die Gelegenheit ergibt, schauen Sie gern noch einmal darauf, und falls Ihnen etwas nicht gefällt oder Sie etwas verbessern möchten, melden Sie einfach ein Issue oder schicken Sie einen PR!

[shaun0927]

Ich denke, parallele Worktrees folgen dem Ansatz „work dirty -> clean nicely“,
und ich glaube, dass das künftig zur wichtigsten Entwicklungsweise wird.
Scheint ein gutes Repo zu sein.

[erish2150]

Vielen Dank :) Sie haben die Punkte, die ich im Kopf hatte, sehr gut aufgeschrieben.

[bigcataroido]

Der worktree-basierte Ansatz, parallele Arbeit zu erzwingen, ist beeindruckend.

Auch ich nutze, wenn ich mehrere Tickets gleichzeitig bearbeite,
eine Kombination aus tmux und mehreren Branches, um die einzelnen Arbeitsumgebungen zu trennen,
aber am Ende hatte ich immer wieder das Problem, dass sich das Zustandsmanagement verheddert hat.

So wie bei parsec den Lifecycle mit start/ship/merge zu bündeln,
scheint eher in die Richtung zu gehen, Fehler zu reduzieren.

Ich hätte dazu eine Frage:
Wenn mehrere PRs gleichzeitig offen sind und sich die Merge-Reihenfolge ändert
oder eine Situation entsteht, in der ein Rebase nötig ist, wie funktioniert dann stack sync?

[erish2150]

Vielen Dank für Ihr Interesse!

stack sync führt Rebase-Vorgänge auf Basis der Eltern-Kind-Beziehungen in topologischer Reihenfolge aus.

Funktionsweise

parsec start PROJ-1                 # basiert auf main  
parsec start PROJ-2 --on PROJ-1     # basiert auf dem Branch PROJ-1  
parsec start PROJ-3 --on PROJ-2     # basiert auf dem Branch PROJ-2  

parsec stack sync                   # automatisches Rebase in der folgenden Reihenfolge  
# 1. PROJ-1 → Rebase auf origin/main  
# 2. PROJ-2 → Rebase auf den Branch PROJ-1  
# 3. PROJ-3 → Rebase auf den Branch PROJ-2  

Die Struktur ist so aufgebaut, dass vom Root aus per BFS traversiert wird und jedes Kind auf den Branch seines Elternteils gerebased wird. Wenn main aktualisiert wurde, werden die Änderungen dadurch natürlich vom Root aus weitergegeben.

Wenn sich die Merge-Reihenfolge ändert

Derzeit ist das System unter der Annahme entworfen, dass von unten im Stack aus, also beginnend bei den Eltern, gemergt wird. Wenn ein PR in der Mitte zuerst gemergt wird, finden die Kinder dieses Knotens beim nächsten stack sync ihren Elternteil nicht mehr und der Vorgang schlägt fehl. In diesem Fall
muss die Base manuell neu zugewiesen werden.

Bei Konflikten

Wenn während des Rebase Konflikte auftreten, wird nur der betreffende Branch mit rebase --abort zurückgesetzt, und der Rest läuft weiter. Da das Ergebnis in einer Tabelle zeigt, welche Tickets erfolgreich waren und welche fehlgeschlagen sind, müssen Sie nur die fehlgeschlagenen manuell beheben.