merge-worktree

Merge Worktree

ブランチの完了時の安全パターンは、MIT ライセンスの finishing-a-development-branch ワークフローを基にしています。正確な固定バージョンと関連性は sources.json に記録されています。

登録済みの Git worktree をマージコミットで統合します。このスキルは統合と worktree のクリーンアップを担当します。実装ワークフローは自らマージせず、このスキルに引き継ぐ必要があります。

認可の確認

リクエストとリポジトリから、次の入力を特定します。

• ソースの worktree パスとブランチ
• ターゲットブランチと、作業ブランチの分岐元
• 統合モード：ローカルまたは GitHub PR
• PR モードの場合、操作：オープンのみまたはチェック後にマージ
• クリーンアップの選択：明示的に --clean-up が指定された場合にのみ有効。それ以外の場合は統合成功後に確認します。

明確な場合に限り、リポジトリのデフォルトブランチを使用します。認可情報が不足している場合は、ローカルでマージする、マージせずに PR をオープンする、PR をオープンしてチェック後にマージする、またはブランチを変更しない、という選択肢を提示します。PR をオープンしても、マージの認可にはなりません。ローカルでマージしても、プッシュの認可にはなりません。

orchestrate-implementation からの候補引き継ぎ

ソースがオーケストレーターの候補である場合、登録済みで親が所有する候補 worktree とブランチのみを受け入れます。引き継ぎには、固定された候補の base/head、正確なレビュー対象範囲、組み立て済みのレーンコミット、重点的な検証、候補のレビュー証拠（必要な場合は新たに実施した独立レビュー、または許可されている低リスクのみの作業では親による確認）、および認可状態を明記する必要があります。削除済みのワーカーパス、ターゲットブランチの現在の HEAD、またはワーカーが報告した SHA を候補ツリーの代わりに使用しないでください。候補の引き継ぎによって、プッシュ、PR のマージ、デプロイ、リリースの権限が与えられることはありません。引き継ぎに含まれる検証証拠は、関連する内容と環境が引き続き一致する場合に再利用できます。実際の統合コミット、参照、アーティファクトの識別情報は、改めて検証します。

事前確認

1. git worktree list --porcelain を実行します。ソースが登録済みの worktree であり、ブランチが切り離されていないことを確認します。
2. ソースとターゲットが同じリポジトリ内の別々のブランチであること、またマージ、リベース、チェリーピックがすでに進行中でないことを確認します。
3. ソースに、ターゲットから到達できないコミットが少なくとも 1 つあることを確認します。すでに統合済みの場合は、その旨を報告してマージをスキップします。
4. ターゲットがチェックアウトされている worktree を特定します。更新する前に、クリーンな状態であることを確認します。
5. ソースの差分とコミットを確認します。無関係な変更、秘密情報の疑い、または所有者が不明確な場合は中止します。
6. リポジトリの指示を読み、ソース worktree で関連する最小限の検証を実行します。または、関連するコード、テスト、入力、環境が正確なソース内容と引き続き一致する、すでに検証済みの証拠を受け入れます。再利用した証拠を記録します。
7. ソースに意図した未コミットの変更がある場合は、そのファイルのみをステージして、簡潔なコミットを作成します。依頼がない限り、既存のコミットを amend しないでください。
8. PR モードでは、選択したリモートを pruning 付きで fetch し、認証の失敗、またはターゲット状態の曖昧さや分岐があれば中止します。ローカルモードでは、リモート追跡ターゲットに対する統合をユーザーが求めた場合に限り、fetch します。

強制プッシュは行わず、ターゲットブランチを推測しないでください。

ローカル統合

候補のマージが成功するまで、対象の参照を変更しないでください。

1. 現在の対象 SHA を記録します。
2. その SHA で一時的な統合ブランチを作成し、登録済みの sibling worktree を作成します。
3. 統合 worktree で、簡潔なメッセージを付けて git merge --no-ff <source-branch> を実行します。
4. コンフリクトが発生した場合は、両方の変更の意図をたどり、各ファイルを慎重に解決します。ファイル全体を一括で ours または theirs にしないでください。生成ファイルでコンフリクトが発生した場合は、手作業で編集せず、生成元のツールを使って再生成します。
5. 関連するチェックを実行します。ただし、統合後の内容がすでに検証済みの内容と同一で、関連する入力と環境に変更がない場合は、引き続き適用できる検証済みの証拠を再利用できます。統合 worktree がクリーンで、コンフリクトがないことを必ず確認します。実際のマージコミット、参照、アーティファクトの同一性は、必ず改めて検証してください。
6. 対象が記録した SHA のままであることを再確認します。変更されている場合は、検証済みの統合 worktree をそのまま残して停止します。
7. 対象を検証済みの統合コミットまで早送りします。対象がチェックアウトされている場合は、そのクリーンな worktree で更新します。それ以外の場合は、対象ブランチの参照が記録した SHA と一致している場合に限り更新します。
8. 対象が統合コミットを指していることを検証します。
9. git worktree remove で一時 worktree を削除し、既知の一時ブランチだけを削除してから、git worktree prune を実行します。

ローカルモードではプッシュしないでください。統合作業のクリーンアップに rm -rf、強制的な worktree 削除、強制更新を使用しないでください。

GitHub PR 統合

構文の変更が多い操作に頼る前に、gh --help と関連する gh pr のヘルプを実行します。その後、次の手順を実行します。

1. gh auth status、選択されている GitHub リモート、現在の対象ブランチを検証します。
2. ソースブランチをアップストリーム追跡付きで通常の方法でプッシュします。
3. 選択したブランチを対象とするオープン中の PR があれば再利用し、なければ作成します。タイトルと本文は、コミットおよび検証の証拠に基づいて作成します。
4. PR の URL を報告します。

オープンのみの場合は、ここで停止します。チェックが完了するまで無期限に待機したり、マージしたり、自動マージを有効にしたり、ソース worktree をクリーンアップしたりしないでください。

チェック後にマージする場合は、その操作について明示的な許可を得たうえで、次の手順を実行します。

1. GitHub がコンフリクトを報告した場合は、現在の対象ブランチを --no-ff でローカルのソースブランチにマージし、慎重に解決して、検証を再実行してから通常の方法でプッシュします。
2. 必須チェックを監視します。チェックが失敗した場合、またはタイムアウトした場合は停止します。ブランチ保護を決して回避しないでください。
3. リポジトリで許可されているマージコミットの方式でマージします。ポリシーでキューまたは自動マージが必要な場合は、回避せずにそのポリシーに従います。
4. クリーンアップ前に、PR がマージ済みであり、リモートの対象ブランチが結果のコミットを含んでいることを検証します。

ソース worktree のクリーンアップ

ローカル統合が成功した後、またはマージ済み PR を検証した後にのみ、次の操作を行います。

• --clean-up が明示的に指定されている場合は、ソース worktree を削除します。
• それ以外の場合は、削除するかどうかを尋ねます。
• クリーンであること、およびそのコミットが統合済みの対象ブランチから到達可能であることを検証します。
• git worktree remove <path> を実行してから、git worktree prune を実行します。
• 別途依頼されていない限り、ローカルブランチまたはリモートブランチを削除しないでください。

作業の破棄を依頼された場合は、まずブランチ、パス、未コミットのファイル、到達不能になるコミットを提示します。固有の作業を削除する前に、完全一致する確認 discard を求めます。ダーティーな worktree を隠すために、強制削除してはなりません。

報告

受けた許可、モード、ソース、対象、マージコミットまたは PR の URL、実行したチェック、リモートにプッシュまたはマージしたかどうか、いずれかの worktree を削除したかどうかを報告します。停止した場合は、失敗したゲートを明示し、復旧可能な状態を保持します。