mcpField
C
commitpush

commitpush

github.com/thatjuan開発150 回インストール3 週間前に更新
リポジトリ

commitpush について

Gitの変更を安全にコミットしてプッシュするための開発スキルです。機密情報の検査やサブモジュールの扱いが必要なワークフローに向け、ステージング前の確認からプッシュ失敗時の復旧までを支援します。

主な機能

  1. 01ステージング前に秘密情報や機密ファイルを検査
  2. 02サブモジュールと変更状態を検出
  3. 03差分を分析してコミットメッセージを作成
  4. 04承認済みの明示的なパスだけをステージング
  5. 05non-fast-forwardによるプッシュ失敗に対応
  6. 06強制プッシュには明示的な承認を要求

活用シーン

  1. 01コミット前に誤って含まれた認証情報を確認
  2. 02コミット対象に含めるサブモジュールを選択
  3. 03リポジトリの履歴に沿ったコミットメッセージを作成
  4. 04プッシュ拒否後にリベースして再試行

インストール

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

$npx skills add https://github.com/thatjuan/agent-skills --skill commitpush

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

同梱ファイルREADME.mdreferences/sensitive-patterns.md

詳細

コミットとプッシュ

ステージングの前にシークレットと機密ファイルを検出し、対象を絞ったコミットに向けてサブモジュールを検出するとともに、プッシュ失敗時の復旧を含むコミットからプッシュまでの一連の処理を実行する、安全なコミット・プッシュワークフローです。

ワークフロー

フェーズ 1:セキュリティチェック

セキュリティチェックは、ステージングを行う前に実行されます。コミットするとリスクとなるファイルや内容を検出します。

検出対象:

  • シークレットと認証情報(API キー、トークン、パスワード、秘密鍵)
  • 機密情報を含む環境ファイルや設定ファイル(.env、.env.*、認証情報ファイル)
  • 証明書と鍵のファイル(.pem、.key、.p12、.pfx、.jks)
  • クラウドプロバイダーの認証情報ファイル(AWS、GCP、Azure の設定ファイル)
  • データベース接続文字列とダンプファイル
  • サイズの大きなバイナリファイルとビルド成果物

チェックの手順:

  1. git status の出力を、既知の機密ファイルパターンと照合します(sensitive-patterns.md を参照)
  2. git diff の内容をスキャンして、インラインのシークレットを検出します。対象はエントロピーの高い文字列、API キーの接頭辞、ハードコードされたパスワード、接続文字列です
  3. 検出されたファイルや内容をユーザーに提示し、除外、続行、中止を推奨します

実際の認証情報を含むかどうかが不明な設定ファイルなど、判断が難しい場合は、処理を進める前にユーザーに確認します。

フェーズ 2:サブモジュールの検出

サブモジュールを含むリポジトリ(ブリッジリポジトリ)では、コミット範囲についてユーザーから明示的な指示を得る必要があります。

検出: git submodule status --recursive でサブモジュールとその変更状態を確認します(+ 接頭辞は未コミットの変更があることを示します)。

変更のあるサブモジュールが存在し、対象範囲が指定されていない場合:

  • 変更のあるサブモジュールと親リポジトリの一覧をユーザーに提示します
  • このコミットサイクルに含める対象をユーザーが選択します
  • 選択されたサブモジュールを先にコミットしてプッシュし(深さ優先)、その後、親リポジトリで更新されたサブモジュール参照をステージングします

サブモジュールがない場合、または対象範囲がすでに指定されている場合: このフェーズはスキップされます。

フェーズ 3:変更の分析

ステージ済みと未ステージの変更を分析し、コミットメッセージの作成に役立てます。

入力:

  • git status — 変更済み、ステージ済み、未追跡ファイルの概要
  • git diff と git diff --staged — 詳細な変更内容
  • git log --oneline -5 — 一貫性を保つための最近のコミットスタイル

コミットメッセージの作成:

  • リポジトリが従来型のコミット形式に従っている場合は、その形式を使用します(最近の履歴から検出)
  • メッセージでは「何を」よりも「なぜ」を重視します
  • 変更範囲が限定されている場合はスコープを含めます(例:fix(auth): ...)
  • コミットメッセージには変更内容の説明だけを記載し、共同作成者の表示は含めません
フェーズ 4:ステージング、コミット、プッシュ

ステージング: フェーズ 1 のチェックで承認されたファイルを、git add で明示的なファイルパスを指定してステージングします。git add . や git add -A のような一括指定コマンドは使用しません。

コミット: フェーズ 3 で作成したメッセージを使用してコミットします。

プッシュ: git push で変更をリモートに送信します。上流の追跡ブランチが設定されていない場合は、git push -u origin <branch> を使用します。

フェーズ 5:プッシュ失敗時の復旧

プッシュが拒否された場合(fast-forward でない場合): git fetch と git rebase を試し、その後プッシュを再試行します。

強制プッシュ: ユーザーから明示的な許可を得る必要があります。--force ではなく --force-with-lease を使用します。

競合または解決できないエラー: 手動で解決できるよう、詳細な状況とともにユーザーに報告します。

リファレンス

ファイル読み込むタイミング
sensitive-patterns.mdフェーズ 1 の実行中 — 機密ファイルのパターンとインラインのシークレットを示す指標の包括的な一覧

引数

ユーザーが任意で指定できるコンテキスト:コミットする特定のファイル、コミットメッセージの上書き、対象範囲の指示(例:「親リポジトリのみ」、「サブモジュール X のみ」)。

コメント