--- title: Git と worktree の戦略 – Agent Teams ドキュメント description: 並列でのエージェント作業において、メインの worktree、機能ブランチ、OpenCode の worktree 分離のどれを使うべきかを判断します。 lang: ja-JP --- # Git と worktree の戦略 Git は Agent Teams に最も強力なレビュー経路をもたらします。差分が狭く、ブランチを把握でき、変更がタスク単位にスコープされ、並列作業をより安全に行えます。 ## 戦略を選ぶ | 戦略 | 使うべき場面 | トレードオフ | | --- | --- | --- | | メイン worktree | 単独での作業、ドキュメントのみの編集、または一度に 1 人のチームメイトのみ | シンプルだが、並列編集が衝突する可能性がある | | 機能ブランチ | 1 つのチームが 1 つのまとまった変更に取り組んでいる | レビュー対象がクリーンになるが、チームメイトは依然としてファイルを共有する | | worktree 分離 | 複数の OpenCode のチームメイトが同じリポジトリを並列で編集する可能性がある | 分離は向上するが、マージ/レビューにより多くの規律が必要になる | シンプルに始めましょう。worktree 分離は、すべてのタスクに別々のチェックアウトが必要だからではなく、並列編集が起こりそうなときに追加します。 ## worktree 分離を有効にするタイミング OpenCode のチームメイトに対して、次の場合に有効にします。 - 2 人以上のチームメイトが同じリポジトリを同時に編集する可能性がある - タスクがフォーマッター、コードジェネレーター、または広範なテストを実行する可能性がある - 各チームメイトのブランチと差分を分離した状態に保ちたい - リードのワークスペースがダーティであり、直接の編集を受け取るべきでない 次の場合はオフのままにします。 - タスクが読み取り専用である - 1 人のチームメイトがすべての編集を担当する - リポジトリが Git で追跡されていない - この分離モードをサポートしないランタイム経路が必要である ::: warning worktree 分離は現在 OpenCode のメンバーに適用され、Git で追跡されたプロジェクトが必要です。 ::: ## ブランチの衛生 並列作業を始める前に行います。 ```bash git status --short git branch --show-current ``` 可能な場合はクリーンなブランチを使いましょう。メイン worktree にすでにユーザーの変更がある場合は、無関係なファイルを元に戻さないようエージェントに伝え、タスクの範囲を狭く保ちます。 推奨されるブランチのスタイル: ```text agent// ``` 例: ```text agent/docs/mcp-guide agent/review/task-log-filtering agent/ui/code-review-polish ``` ## レビューの流れ 分離された worktree については、マージしたり変更をメインのワークスペースに適用し直したりする前に、チームメイトの差分をレビューします。 1. タスクの結果コメントが、変更されたスコープと検証内容を明示していることを確認します。 2. レビュー UI でタスクの差分を確認します。 3. 差分が無関係なファイルに触れている場合は、そのタスクに対して変更を依頼します。 4. テストまたは手動チェックがタスクのリスクに見合った場合にのみ承認します。 5. 慎重にマージまたは変更を適用します。 タスクが完了したというだけで worktree の出力を自動マージしないでください。完了とは、エージェントがその作業をレビューする準備が整ったと考えていることを意味します。 ## コンフリクトのポリシー 並列チームには次のポリシーを使います。 | 状況 | 対応 | | --- | --- | | 2 人のチームメイトが同じファイルを編集する | 一方のタスクを一時停止するか、1 人を統合の責任者にする | | 生成ファイルが広範に変更された | ジェネレーターとコマンドを説明するコメントを必須にする | | メイン worktree に無関係な変更がある | それらを保持し、タスクが所有する変更のみをレビューする | | worktree のブランチが分岐している | レビューの後に手動でリベースまたはマージし、あいまいなエージェントタスクの中では行わない | ## タスクプロンプトの例 ```text Implement the settings validation fix in your assigned worktree. Keep edits inside src/features/settings and focused tests. Do not touch provider auth or task storage. Post the test command and result before completing the task. ``` このプロンプトがうまく機能するのは、許可された領域、機微な境界、完了の証拠を明示しているからです。 ## 関連ガイド - [チームの作成](/ja/guide/create-team) - [コードレビュー](/ja/guide/code-review) - [チームブリーフの例](/ja/guide/team-brief-examples) - [ランタイムの設定](/ja/guide/runtime-setup)