mcpField
G
git-integrate

git-integrate

github.com/legendapp開発38389 回インストール5 日前に更新
リポジトリ

git-integrate について

git-integrate は、指定された rebase、merge、cherry-pick、revert を検証まで進めるスキルです。Git の状態を確認し、リポジトリの情報に基づいて競合を扱い、操作や解決方針が不明な場合は確認のため停止します。

主な機能

  1. 01rebase、merge、cherry-pick、revert に対応
  2. 02進行中の Git 操作状態を確認
  3. 03リポジトリの情報に基づく競合解決
  4. 04履歴と操作完了を検証
  5. 05意図が不明なら停止して確認

活用シーン

  1. 01進行中の Git 統合作業を続行
  2. 02指定されたコミットやブランチを適用
  3. 03統合時の競合を確認して解決

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/legendapp/legend-skills --skill git-integrate

インストール後、Claude Code で/git-integrateを入力して読み込まれたか確認します。

同梱ファイルagents/openai.yamlscripts/inspect-operation.sh

詳細

Git 統合

リベース、マージ、チェリーピック、またはリバートを、完了を検証するところまで担当します。ユーザーが統合または復旧を依頼し、操作が進行中の場合は、それを続行または修復します。無関係なタスク、監査、質問は、履歴操作を再開する許可にはなりません。それ以外の場合は、ユーザーが明示的に依頼した操作を開始します。これは汎用の Git コマンド実行機能ではありません。統合方法を選択したり、無関係なコミット、ブランチ、スタッシュ、リセット、リモート、ワークツリーのメンテナンスを行ったりしないでください。

厳守事項: 新しい作業では、依頼、リポジトリのポリシー、または既存の設定によって、依頼された操作と意図する履歴が明確になった場合に進めます。進行中の操作では、Git の状態から操作と次のアクションが明らかな場合、ユーザーに方法や対象を改めて確認することなく続行します。競合の解決は、意図する結果もリポジトリの根拠から明確な場合にのみ行います。それ以外の場合は、Git やファイルを変更する前に停止し、具体的な選択肢を示してユーザーに確認します。決して既定の選択肢を選ばないでください。誤った履歴操作や解決を行うより、作業を中断するほうがよいからです。

ワークフロー

  1. 状態を確認します。 git status の全出力、git status --short --branch、および利用可能な場合は scripts/inspect-operation.sh を実行します。現在のブランチと HEAD を記録します。git rev-parse --git-path を使って、rebase-merge、rebase-apply、MERGE_HEAD、CHERRY_PICK_HEAD、REVERT_HEAD、およびシーケンサーディレクトリの場所を特定します。

    進行中の Git の状態によって、続行する操作が決まります。別の操作を開始したり、新しい方法や対象をユーザーに選ばせたりしないでください。ただし、状態だけでは、意図する統合後の動作が明確になるわけでも、--continue が直ちに正しいアクションだと確認できるわけでもありません。

  2. 進行中の操作を続行します。 git status、操作のメタデータと todo の状態、現在の操作対象コミット、未マージのインデックスステージ、ステージ済みの変更、ワークツリーの変更を確認します。操作が続行可能な状態なのか、競合、編集指示、exec の失敗、空のコミット、保留中のコミット、または別の理由で停止しているのかを判断します。

    競合は、以下の解決ワークフローに従って処理します。編集または exec の失敗の場合は、続行する前に、依頼された編集またはコマンドの結果を検証します。空のコミットの場合は、それを保持、削除、スキップする前に、明示的な承認を求めます。停止理由または次のアクションが不明確な場合は、正確な状態を維持して確認します。操作が進行中であるというだけで、決して盲目的に続行しないでください。

  3. 新しい操作の事前確認を行います。 進行中の操作がない場合は、明示的に指定された方法と、履歴への正確な影響を判断するために十分な情報が必要です。

    • リベース:現在のブランチまたは指定されたソースブランチ、上流、再適用するコミット、および依頼で --onto、--rebase-merges、--update-refs、autosquash、またはその他の非既定の形式が必要かどうか。
    • マージ:ソースとターゲット、および意図する早送りポリシー。--ff-only、早送りを許可する、または --no-ff でマージコミットを必須にする、のいずれか。
    • チェリーピック:対象となる正確なコミット、その順序、および空の結果が発生した場合に停止、削除、保持のどれにするか。
    • リバート:対象となる正確なコミット、その順序、およびすべてのマージコミットについて確認済みの -m <parent>。

    名前付きの参照をコミット ID に解決し、履歴を変更する前に、マージベース、分岐状況、コミット、関連する差分を確認します。既存のステージ済み、未ステージ、未追跡の変更を特定します。それらの所有者と操作への非干渉が明確な場合にのみ、変更を残したまま進めます。鮮度が重要な場合に限り、必要なリモートまたは参照だけをフェッチします。merge.ff、rebase.autoStash、rebase.rebaseMerges、rebase.updateRefs、rerere.enabled など、動作に影響する設定を確認します。設定が結果を大きく左右する場合は、明示的なフラグを使うか、ユーザーに確認します。

    依頼されていない統合方法を選択したり、意図するトポロジーを変更したり、無関係な作業をスタッシュしたりしないでください。通常のオプションには、リポジトリで確立された設定を使用します。選択肢によって依頼された結果が大きく変わる場合は、ユーザーに確認します。最終的な履歴と比較できるよう、元のブランチ、HEAD、関連する参照を記録します。

  4. 確認済みの操作を開始します。 すべてのリクエストを単純な形式に押し込まず、確認済みの履歴の形に基づいてコマンドを構成します。基本的な形式には、git rebase <upstream>、git merge --no-edit --ff-only <source>、git merge --no-edit --ff <source>、git merge --no-edit --no-ff <source>、git cherry-pick <commits>、GIT_EDITOR=true git revert <commits>があります。確認できた場合に限り、バリエーション用のフラグや -m <parent> を追加します。要求されたコミットメッセージと動作を維持できる場合は、非対話形式で実行します。

  5. 編集する前に、すべての競合を調査します。 git diff --name-only --diff-filter=U、git ls-files -u、git diff --cc、競合マーカーを確認し、さらに REBASE_HEAD、CHERRY_PICK_HEAD、REVERT_HEAD、または MERGE_HEAD が示す正確な変更を調べます。周辺の履歴、呼び出し元、テスト、ドキュメントを使って、各パスで意図される結果とその根拠を明らかにします。

    意図する結果が確定している独立したパスは解決します。競合する動作が未解決のパスは保持して確認を求めますが、それらによって明確な解決の調査や準備を妨げないようにします。正確な Git の状態とパスを報告し、競合する意図と根拠を説明して、具体的な選択肢を提示します。最も可能性の高い選択肢を示してもかまいませんが、自分で選んではいけません。動作が異なる場合、削除と変更の競合が不明確な場合、バイナリ/ロック/生成ファイルに確証がない場合、リファクタリングや根拠が競合する場合、メインラインの親が指定されていない場合は、必ず確認を求めます。フォーマット、インポート、重複しない編集、移動、生成ファイルについては、リポジトリ内の根拠から結果を確認できる場合に限り、直接解決します。

  6. 解決して検証します。 ステージ済みの解決、rerere、マージドライバー、自動解決は、信頼できない提案として扱います。すべてのパスの意図が明確になったら、ファイルを編集し、生成ファイルはそのソースから再生成して、すべてのマーカーを削除し、解決済みのパスのみをステージします。未マージのエントリが残っていないことを確認し、ステージ済みの解決内容をレビューして、中間状態でテスト可能なら、最も速くて適切な範囲のチェックを実行します。独立した検証なしに、ours、theirs、union merge、生成出力を丸ごと採用してはいけません。

  7. 進行中の操作を続行します。 競合の解決後や保留中の操作コミットの確認後など、Git の状態から現在のステップを完了できると判断できる場合は、対応するコマンドを使います。

    • GIT_EDITOR=true git rebase --continue
    • GIT_EDITOR=true git merge --continue
    • GIT_EDITOR=true git cherry-pick --continue
    • GIT_EDITOR=true git revert --continue

    続行のたびに状態を再確認します。その後の各停止にも同じ分類と厳格な停止条件を適用し、必要な処理を確認せずに、別の停止理由に対して --continue を使ってはいけません。

  8. 完了を検証します。 操作状態を示すファイルがなくなっていること、最終ブランチと HEAD が想定どおりであること、要求されたコミットと履歴構造が誤った削除や重複なく存在することを確認します。複雑なリベースでは、実用上可能な場合に git range-diff または同等の根拠を用いて、変更前後のコミット列を比較します。対象を絞った検証を実行し、最終ステータスと残っている変更を確認してから、操作、解決したパス、履歴の検証、検証結果、残りのツリー状態を報告します。

Ours と Theirs

  • リベース:ours は新しいベース上に積み上げられたリベース後の結果で、すでに再適用されたコミットを含みます。theirs は現在再適用中のコミットです。
  • マージ:ours は現在のブランチです。theirs はマージ対象のブランチです。
  • Cherry-pick:ours は現在の HEAD で、シーケンス内ですでに適用されたコミットを含みます。theirs は適用中のコミットです。
  • リバート:ラベルから推測してはいけません。現在の HEAD、リバート対象のコミット、その選択された親、およびインデックスのステージを比較します。

安全性

明示的な承認なしに、破壊的なリセットを実行したり、操作を中止または終了したり、コミットをスキップまたは削除したり、無関係な変更を上書きしたり、要求された履歴のトポロジーを変更したりしてはいけません。完了したかどうかが不明確、または安全でない場合は、正確な状態を保持し、解決方法の案内を提供するか、対応する復旧コマンドを使用するか、別の統合方法を選択するかを確認してください。

scripts/inspect-operation.sh は、実行中の操作、現在のブランチとコミット、操作のメタデータ、ステージ済みパスと競合しているパス、インデックスのステージ、マーカーの位置を表示します。

コメント