Jesse Vincent (obra) / using-git-worktrees
コーディングエージェントは別の git worktree で作業すべきか
機能開発ならたいていはそうです。そしてこのスキルの大部分は、すでにある worktree を重ねて作らないための手順です。
押さえておく点
- 隔離が必要な機能開発を始めるときや計画を実行する前に読み込まれ、読み込まれたことを宣言します。
- 作る前に検出します。git-dir と git-common-dir を比べ、サブモジュールも見分け、すでにいる worktree の中に 2 つ目を作ることはありません。
- スキルが EnterWorktree や --worktree オプションのような名前で例示するネイティブ機能が、git worktree add より優先されます。後者は実行環境から見えない状態を残すからです。
- 基準のテストが失敗していれば無視せず報告します。後の失敗を、もともとあった失敗と取り違えないためです。
01実務で何が変わるか
メインの作業コピーを直接編集するエージェントが失敗すると、選択肢はどちらも悪いものになります。エージェントの変更と自分の変更を切り分けるか、両方捨てるかです。worktree は同じリポジトリ上にエージェント専用のディレクトリとブランチを与えるので、失敗した試みの後始末はフォルダーを 1 つ消すだけで済みます。
スキルの大部分は、隔離の重複を避けるためにあります。実行環境によっては、各エージェントを自分で管理する worktree の中で動かします。その上でエージェントが git worktree add を実行すると、スキルの言う幽霊の状態、つまり実行環境から見えず片付けもできない作業場所が生まれます。手順 0 でまず確認し、手順 1 でネイティブ機能を優先し、git に頼るのは最後です。
- ディレクトリの選択: 明示された希望、次に既存の .worktrees か worktrees フォルダー、どちらもなければプロジェクト直下に新しい .worktrees。
- 準備: 見つかったファイルに応じて npm install、cargo build、pip install、poetry install、go mod download のいずれか。
- 基準: プロジェクトのテストコマンド。失敗は作業開始前に報告されます。
02期待に届かない点
準備の手順は、ファイル名による固定の対応表です。pyproject.toml があれば poetry install が走るので、別のツールで管理しているプロジェクトでは誤りになります。直下にマニフェストが複数あるリポジトリでは、合致するコマンドがすべて実行されます。珍しい構成では手直しが必要です。
1 つの場面では、スキルが自分でリポジトリに手を入れます。worktree 用のディレクトリが無視設定になっていなければ、.gitignore に追加してコミットします。リポジトリにとっては安全な既定動作ですが、それでも自分で書いていないコミットです。履歴を気にするなら、その行は自分で追加してください。
導入と最初の実行
- Claude Code では /plugin install superpowers@claude-plugins-official で superpowers を導入します。コレクションのライセンスは MIT で、このスキルは git とプロジェクト自身のツールを前提とする SKILL.md 1 つだけです。
- git による代替手段が使われそうなら、先に自分で .worktrees/ を .gitignore に追加しておきます。そうしないと、スキルがその行を追加し、現在の作業コピーでコミットします。
- 作業を続けさせる前に、テスト基準の報告を読みます。変更前からテストが失敗していれば、スキルは止まって確認を求めます。判断するのはそのときです。
実際によくある質問
- git worktree とは何ですか
- 同じリポジトリに結び付いた 2 つ目の作業ディレクトリで、独自のブランチをチェックアウトします。2 つの作業がディスク上のファイルを共有せずに済みます。
- 確認なしに worktree を作りますか
- 作りません。通常の作業コピーでは、指示の中で希望が示されていない限りまず確認し、断ればその場で作業します。
- どの superpowers スキルがこれに依存していますか
- executing-plans と subagent-driven-development が、開始前に作業場所を作るか既存のものを確認するために呼び出します。
出典
このページの機械可読版