worktree-merge

Worktree Merge

作業ブランチに機能ブランチを任意の数だけ統合するには、使い捨ての統合ブランチを1つ経由します。すべてのブランチのマージとテストスイート全体の合格が確認されるまで、メインラインには何も反映されません。検証コマンドはリポジトリから検出し、決めつけることはありません。

入力

$ARGUMENTS は統合するブランチの一覧です。

• 2つ未満の場合 → 統合するブランチを尋ねてください。推測しないでください。
• 2つ以上の場合 → 指定された順番で統合してください。

検証コマンドを一度だけ検出する

このプロジェクトが正常に動作することを確認できるコマンドを特定します。CIで実行されているコマンドを優先してください。.github/workflows/*、Makefile、またはマニフェストのテスト／lintスクリプトを確認し、それらと同じコマンド（テストランナー、型チェッカー、リンター）を使います。pytest／mypy／pyright をハードコードせず、このリポジトリで実際に使われているものを使用してください。

手順

1. 前提条件。 worktrees/ 内ではなく、リポジトリのルートにいることを確認します（[[ $(pwd) =~ /worktrees/ ]] → エラー）。現在のブランチを保存します。一覧内のすべてのブランチが存在することを確認します（git rev-parse --verify <branch>）。いずれかのチェックに失敗した場合は、明確なメッセージを表示して早期に中止します。

2. 統合ブランチを1つ作成します。現在のブランチから分岐させ、対象ブランチの一覧にちなんだ名前を付けます（例：integration-<first>。複数ある場合は短い接尾辞を付け、ファイルシステムで安全な名前にします）。ここでマージをテストし、最後までメインラインには手を加えません。

3. 各ブランチを順番にマージします。--no-ff を使います。マージのたびに、検出したテストコマンドを実行し、問題の原因となったブランチを特定できるようにします。

   • 競合が発生した場合： 中止し、競合しているブランチとファイルを示して、解決手順（解決 → git add → git commit → スキルを再実行）を案内します。自動で解決しようとしないでください。
   • テストに失敗した場合： 中止し、失敗したテストを報告して、ロールバック手順（git checkout <original> → git branch -D <integration>）を案内します。

4. すべてのブランチのマージ後に完全な検証を一度実行します。プロジェクトで検出した完全なテストスイート（テスト + 型チェック + lint）を実行します。失敗があれば報告してロールバックします。失敗した状態でメインラインに反映されることはありません。

5. 統合ブランチを元のブランチにマージし（--no-ff）、その後、統合ブランチを削除します。

6. AskUserQuestion を使ってクリーンアップを提案します。N 個のワークツリーを削除して機能ブランチを削除するか、そのまま残すかを尋ねます。 「はい」の場合、各ブランチについて次を実行します：git worktree remove worktrees/<branch> および git branch -d <branch>。

報告

• 成功： 使用した統合ブランチ、マージした各ブランチ（マージ後のテスト結果を含む）、完全な検証結果、<original> へのマージ結果、クリーンアップ状況（ワークツリーを残したか削除したか。残した場合は手動で実行するクリーンアップコマンドを含む）。
• 失敗： 失敗した手順とブランチ、現在のブランチの状態、正確なロールバックコマンド（git checkout <original> → git branch -D <integration>）、修正後の続行方法（同じブランチ一覧を指定して再実行）。

備考

• --no-ff を使うと、各機能ブランチの履歴が保持されます。
• 統合ブランチは破棄可能です。すべてのマージとテストスイート全体の合格が確認されるまで、元のブランチは変更されません。
• チームで作業している場合は、ブランチごとにPRを作成することを推奨します。このスキルは、自分でマージを管理する場合の迅速なローカル統合向けです。