worktrunk は Rust で書かれたコマンドラインの道具で、Git の作業ツリーを専門に扱う。作業ツリーを作り、そこへ切り替え、終わったら統合し、最後に片付ける、という一連の動作を数個の命令に畳み、さらにプロジェクトごとのフックで新しいディレクトリに依存パッケージを入れさせたりサービスを起動させたりできる。プロジェクトの表紙にははっきり書いてある。エージェントを並行して走らせる流れのための道具だと。一つのリポジトリに対して三つ四つのコーディングエージェントを動かす人に、いちばん効く。Windows、macOS、Linux で動き、現在の版は 0.81 だ。

作業ツリーに専用の命令が要る理由

Git の作業ツリー自体は込み入っていない。一つのリポジトリから複数のブランチを別々のディレクトリに取り出せ、互いに干渉せず、stash で行き来する必要もない。面倒なのは操作のほうだ。元の命令はパスとブランチ名を要求し、切り替えたあとも自分で cd する。ディレクトリが五つ六つになると、どのブランチがどこまで進み、main に遅れているかは頭の中に置くことになる。

もっと現実的な問題はエージェントだ。エージェントにリポジトリの中でコードを書かせると、作業ディレクトリは途中の状態になる。二つ目を動かせば互いに踏み合う。エージェントごとに独立した作業ツリーを渡すのが最もきれいな答えで、それを手作業で毎日やるのが面倒な部分になる。

wt switch はブランチではなくディレクトリを移す

wt switch の後ろにブランチ名を置く。ブランチがなければ作業ツリーを作り、あればそこへ移る。元の命令との違いは shell との統合にある。導入後に切り替えると端末の作業ディレクトリも一緒に移るので、cd を打ち直さなくてよい。命令を一緒に走らせることもでき、二重の横棒のあとに引数を並べる。これで「ツリーを作る、ディレクトリに入る、エージェントのセッションを起こす」が一歩になる。

新しいツリーの中は依存も設定も空で、そこをフックが埋める。プロジェクトの設定に起動手順を書いておけば、パッケージの導入、データベースの初期化、ローカルサービスの起動を、新しいツリーごとに自動で実行する。フックの前に、このプロジェクトを信頼するかを尋ねる。リポジトリを複製しただけで他人の命令が黙って走る事態を避けるためだ。

wt list はすべてのツリーを一表で見る

命令を打つと表が出る。一行が一つの作業ツリーで、ブランチ名、作業領域の状態、コミット、main に対する先行と遅れ、遠隔との差、最後のコミットの時刻とメッセージが並ぶ。作ったばかりで読み込みが終わっていないツリーは読み込み中と表示され、数秒で埋まる。

状態の列を見れば、未コミットの変更、衝突、統合の進行がディレクトリを回らずに分かる。先行と遅れの列は、どのツリーが main に遅れ、どれが遠隔まで届いているかを一度の走査で示す。メッセージの列は、自動で作られるコミットの説明と合わせて、そのツリーが何をしているかを一行で語る。

統合と片付けにも決まった形がある

仕事には終わりが要る。wt merge は今のツリーの変更をコミットし、目標のブランチにrebase し、fast-forward で進め、そのあと作業ツリーとブランチを片付ける。すべて裏で進むので、命令を打ち続けられる。ブランチの履歴を残したいリポジトリ向けに、統合コミットを作ることもできる。

要らなくなったら wt remove。消したツリーはすぐには消えず、.git/wt/trash という戻し場所に入るので、誤って消しても取り返せる。たまってきたら prune で片付ける。ブランチが既定のブランチに統合済みのツリーは消え、未統合のものと作ったばかりのものは飛ばされ、最短の生存時間で規模を抑えられる。

エージェントごとに自分のディレクトリを

エージェントを並行で走らせるときに邪魔なのは、git に無視されているファイルだ。node_modules、ビルドの産物、ローカルの環境変数。新しいツリーではこれらが空なので、エージェントは最初に入れ直しに時間を使う。wt は無視ファイルを元のツリーから複製でき、衝突する値、たとえばポート番号やデータベース名を書き換えて、二つのツリーのローカルサービスが同じポートを取り合わないようにする。

worktrunk は MIT と Apache 2.0 の二重ライセンスで、ソースは GitHub にあり、文書の site も揃っている。特定のエージェントに縛られず、端末から起動できる道具なら何でも、この「命令付きで切り替える」引数から新しいツリーに入れられる。

使う価値はあるか

ブランチを一本しか持たない人には要らない。元の git で足りる。効くのは二つの状況だ。無関係な機能の線を同時に何本も進めるとき、あるいは二つ三つのエージェントに同じリポジトリを並行で触らせるとき。前者はディレクトリ管理の時間を、後者は上書きされたあとの調査の時間を節約する。

代わりに、命令の層がもう一枚増える。wt には独自の副命令と設定があり、フックを書き間違えれば新しいツリーは起動しない。shell との統合も前提で、その一歩を入れなければディレクトリの切り替えは手作業に戻る。

worktrunk のやっていることは小さい。Git の作業ツリーを「そんな機能があると知っている」ものから「毎日使う」ものへ移しただけだ。新しい仕組みを発明したわけではない。ツリーを作る、状態を見る、統合する、片付けるという四つを手に馴染む命令にし、新しいディレクトリが自力で立ち上がるようフックの層を足した。エージェントを並行で走らせる流れでは、この手軽さは値段に見合う。