merge-base-branch

選択したベースブランチを現在のブランチにマージし、リンターのチェックが問題なく完了し、テストカバレッジが完全で、ビルドが成功する状態にします。ブランチを親ブランチと完全に同期し、CI 品質のチェックをローカルで通過させたい場合に使用します。

使い方：

• /merge-base-branch — 以下のワークフローをすべて実行します

前提条件：

• リポジトリのルートは git チェックアウトであり、名前付きブランチ上にある必要があります（detached HEAD は不可）。
• プロジェクトが Node/npm を使用する場合、package.json で lint、test:coverage、build の各スクリプトが定義されている必要があります。package.json がない場合、またはこれらのスクリプトが1つでも欠けている場合は、何が不足しているかを報告して停止します（必須のチェックを実行せずにマージや処理を進めてはいけません）。

手順：

1. 現在のブランチ：

   • git branch --show-current を実行します。detached HEAD の場合はユーザーに知らせて停止します。

2. ベースブランチ候補を特定してから、ユーザーに選択してもらう：

   • まず、リポジトリのルートに .agent がある場合は、baseBranch=<value> を読み取ります。その値が検出された候補です（存在する場合）。
   • それ以外の場合は、git から推定します。git merge-base --fork-point main HEAD、git merge-base --fork-point master HEAD、git merge-base --fork-point develop HEAD を実行します。コミットを返したブランチ名は一致とみなします。一致が1つだけの場合、それが検出された候補です。複数一致する場合は、main、master、develop の優先順位で選択します。一致するものがない場合、検出された候補は未設定です。
   • AskUserQuestion を使い、マージするベースブランチをユーザーに選んでもらいます。選択肢には必ず main を含めます。検出された候補が設定されていて main と異なる場合は、それも選択肢に含めます。origin に存在する（またはローカルに存在する）場合は、master と develop も追加の選択肢として含めます。各選択肢には短い説明を付けます（例：「履歴から検出：develop」）。回答を待ち、選択されたブランチを <base-branch> とします。

3. ベースブランチを確認してフェッチする：

   • git rev-parse --verify origin/<base-branch> を実行して確認します。失敗した場合は git rev-parse --verify <base-branch> で確認します。どちらも存在しない場合はユーザーに知らせて停止します。
   • git fetch origin <base-branch> を実行します。失敗した場合はエラーを表示して停止します。

4. ベースブランチとすでに同期済みの場合は停止する：

   • フェッチ後にその参照が存在する場合は <merge-ref> を origin/<base-branch> とし、存在しない場合は <base-branch>（ローカルのみ）とします。
   • git rev-list --count HEAD..<merge-ref> を実行します（同等の方法として、git log --oneline HEAD..<merge-ref> にコミットがないことを確認します）。
   • コミット数が0の場合、現在のブランチにはすでに <merge-ref> のすべての変更が含まれており、マージは不要であることをユーザーに伝えます。作業ツリーがクリーンでない場合は、未コミットの変更が残っていることも伝えます。停止します（このワークフローでは WIP をコミットせず、マージも lint／テスト／ビルドも実行しません）。

5. マージ前に未コミットの作業をすべてコミットする：

   • git status にコミットが必要なステージ前／ステージ済み／未追跡の変更が表示されない場合は、手順6に進みます。
   • それ以外の場合は、作業ツリー内のすべてをステージしてコミットします（現在のセッションで変更したファイルだけに限定しません）。差分に明確に別々の論理的なまとまり（例：機能領域やディレクトリごとのグループ）が含まれる場合は、複数のコミットに分けます。各コミットには内容が明確に分かるメッセージを付けます。git add で個別に選択する（または git add -p を使う）ことで、まとまりのあるコミットを作成します。複数の異なるまとまりがある場合に、無関係な作業を1つのコミットにまとめてはいけません。

6. ベースブランチをマージする：

   • git merge origin/<base-branch> --no-edit を実行します（origin/<base-branch> が存在せず、ローカルブランチが存在する場合に限り、git merge <base-branch> --no-edit を使用します）。
   • マージが成功した場合は、マージしたコミットを簡潔にまとめます。

7. 競合を解決してマージを完了する：

   • 競合がある場合は、git diff --name-only --diff-filter=U でファイルを一覧表示します。各ファイルを解決し（競合マーカーを削除し、意図に沿って統合または選択します。上流の修正はベースブランチを優先し、機能コードは現在のブランチのものを維持します）、解決した各ファイルを git add してから、マージが完了するまで git merge --continue --no-edit を実行します。

8. Lint：

   • リポジトリのルートから npm run lint を実行します。報告された問題をすべて修正し、成功するまで再実行します。

9. Lint 後のコミット（変更がある場合）：

   • Lint の修正（またはフォーマッターによる変更）でファイルが変更された場合は、適切なメッセージを付けてコミットします（変更内容に応じて、複数のコミットに分けてもかまいません）。

10. カバレッジ付きテスト：

    • npm run test:coverage を実行します。失敗した場合は、カバレッジレポートとエラー出力を確認し、すべての行が 100% カバーされるまで（プロジェクト／ツールの基準に従って）テストを追加または調整します。コマンドが成功するまで、再実行と調整を繰り返します。

11. テスト／カバレッジ関連の変更をコミット：

    • 手順 10 で行ったテストまたはソースの変更を、分かりやすいメッセージを付けてコミットします。

12. ビルド：

    • npm run build を実行します。コンパイルまたはバンドラーのエラーを修正し、成功するまで再実行します。

13. ビルド修正のコミット（修正がある場合）：

    • 手順 12 でファイルが変更された場合は、コミットします。

ユーザー向けの概要： 使用したベースブランチ、マージ結果（または「すでに最新の状態」）、Lint／テスト／ビルドの結果、および実行中に作成したコミットの一覧。