git-parsec — 1つのチケットでworktree作成からPRマージまで

 (github.com/erishforG)
4 ポイント 投稿者 erish2150 2026-04-21 | 6件のコメント | WhatsAppで共有

Git worktreeベースの並列開発ワークフローを自動化するCLIツールです。

解決する課題

ブランチを切り替えずに複数のチケットを同時に進める場合、git worktreeは優れた選択肢です。
ただし実務で使うには、繰り返し作業が多く発生します。

  • worktreeを作成してブランチ名を付ける → parsec start PROJ-123 の1行で
  • pushしてPRを作成し、チケットリンクを付ける → parsec ship PROJ-123 の1行で
  • CIを確認してマージし、worktreeを整理する → parsec merge PROJ-123 の1行で

毎回繰り返していた作業が、それぞれ1行のコマンドに減ります。

コアワークフロー

parsec start PROJ-123       # worktree + ブランチ + Jiraチケット連携  
# ... コーディング ...  
parsec ship PROJ-123        # push → PR作成（チケットタイトル/リンクを自動で含む）  
parsec ci PROJ-123          # CIステータステーブルを出力  
parsec merge PROJ-123       # CI待機 → squashマージ → worktree自動整理

主な機能

トラッカー連携

  • Jira / GitHub Issues — チケットタイトルの自動反映、ステータス遷移、ボードビュー、インボックス
  • parsec ticket — ターミナルでチケット詳細を表示
  • parsec board — JiraスプリントボードをCLIで確認

worktree管理

  • Shell統合 — parsec switch でworktree間の cd 移動を自動化
  • スタックPR — --on オプションでPRチェーンを構成し、stack sync で一括rebase
  • Undo — 誤って整理したworktreeも一発で復旧

自動化

  • Release — タグ + マージ + GitHub Release + changelogを自動生成
  • Human / JSON / Quiet 出力モード — CIスクリプトと連携しやすい
  • 27個のサブコマンド — start, list, status, ship, merge, ci, diff, sync, adopt, rename など

インストール

cargo install git-parsec

または GitHub Releases から macOS / Linux バイナリをダウンロードできます。

こんな方におすすめです

  • 複数のチケットを同時に進める方（worktreeベースの並列開発）
  • Jira + Git 間の繰り返し作業にうんざりしている方
  • モノレポでコンテキストスイッチのコストを減らしたい方
  • AIエージェント（Claude Code など）に独立した作業環境を与えたい方

リンク

Rustで書かれており軽量で、既存のgitリポジトリにそのまま適用できます。
フィードバックや質問も歓迎です！

関連記事

6件のコメント

 
puddingman220 2026-04-22

最近、並列worktreeに関する技術ブログを見て興味を持ったものの、実装内容までは見られず残念だったので、このオープンソースで一度深く掘り下げてみたいですね！

以下は私が読んだブログ記事です。
https://medium.com/ajd-tech/…
 
erish2150 2026-04-22

ありがとうございます！ ブログに書いていただいた内容も軽く拝見しましたが、とても素晴らしくまとめてくださいましたね。
機会があればぜひご覧いただいて、気に入らない点や改善したい点などがあれば、気軽に issue を登録するか PR を送ってください！
 
shaun0927 2026-04-21

並列 worktree は work dirty -> clean nicely というやり方だと考えていて、
これが今後の主な開発スタイルになると思います。
良いリポジトリだと思います。
 
erish2150 2026-04-21

ありがとうございます :) 私が考えていた点をうまく書いてくださっていますね。
 
bigcataroido 2026-04-21

worktreeベースで並列作業を強制するアプローチが印象的ですね。

私も複数のチケットを同時に処理するとき、
各作業環境を分離するために tmux + 複数の branch の組み合わせで運用しているのですが、
結局は状態管理がずっとこんがらがる問題がありました。

parsec のように start/ship/merge でライフサイクルをまとめてしまうほうが、
むしろミスを減らす方向になりそうですね。

気になる点があるのですが、
複数の PR が同時に上がっている状態で merge の順番が変わったり、
rebase が必要な状況では stack sync はどのように動作するのでしょうか?
 
erish2150 2026-04-21

ご関心をお寄せいただきありがとうございます！

stack sync は、親子関係に基づいてトポロジカル順序（topological order）で rebase を実行します。

動作方式

parsec start PROJ-1                 # main ベース  
parsec start PROJ-2 --on PROJ-1     # PROJ-1 ブランチ ベース  
parsec start PROJ-3 --on PROJ-2     # PROJ-2 ブランチ ベース  

parsec stack sync                   # 以下の順序で自動 rebase  
# 1. PROJ-1 → origin/main の上に rebase  
# 2. PROJ-2 → PROJ-1 ブランチの上に rebase  
# 3. PROJ-3 → PROJ-2 ブランチの上に rebase

ルートから BFS で巡回しながら、各子を親ブランチの上に rebase する構造です。main が更新されると、ルートから変更が自然に伝播します。

merge の順序が変わる場合

現在は、スタックの下側（親）から merge することを前提に設計されています。もし途中の PR が先に merge されると、そのノードの子は次回の stack sync 時に親を見つけられず失敗します。この場合は、手動で base を再指定する必要があります。

競合発生時

rebase 中に競合が発生した場合は、そのブランチだけを rebase --abort でロールバックし、残りはそのまま続行します。どのチケットが成功／失敗したかはテーブルで表示されるため、失敗したものだけ手動で解決すれば大丈夫です。