mcpField
C
commit-push

commit-push

github.com/existential-birds開発8564 回インストール11 週間前に更新
リポジトリ

commit-push について

commit-pushは、Conventional Commits形式でローカル変更をコミットし、リモートへプッシュするスキルです。差分、ステージ済みファイル、対象ブランチとリモート、プッシュ後の状態を順に確認します。

主な機能

  1. 01作業ツリーと差分を確認
  2. 02Conventional Commits形式のメッセージを作成
  3. 03コミット前にステージ済みファイルを確認
  4. 04プッシュ前にブランチとリモートを確認
  5. 05プッシュ後に作業ツリーと同期状態を確認

活用シーン

  1. 01レビュー済みのローカル変更をコミット
  2. 02指定したブランチとリモートへ変更をプッシュ
  3. 03プッシュ後にリポジトリの同期状態を確認

インストール

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

$npx skills add https://github.com/existential-birds/beagle --skill commit-push

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

詳細

コミットしてプッシュする

すべてのローカル変更を Conventional Commits 形式でコミットし、リモートにプッシュします。

ゲート

順番に完了してください。合格条件を満たすまでは、次の操作を実行しないでください（記憶ではなく、コマンドの出力を根拠として使用してください）。

  1. 差分の内容を把握 — 合格条件： git status、git diff、git diff --cached の出力が、変更内容を一文で説明した内容と一致している（または、コミットする変更がないと記録している）。
  2. コミット行を決定 — 合格条件： 出荷する変更セットに合った、先頭行の案 type(scope): description（scope を省略する場合は type: description）がある。
  3. ステージングが意図と一致 — 合格条件： git add の後、git diff --cached --stat（必要に応じて git diff --cached も確認）に、含める予定のパスのみが表示されている。一致しない場合は、コミット前にステージングを調整する。
  4. プッシュ先を確認 — 合格条件： 現在のブランチとリモートが意図したものになっている（git branch -vv、git remote -v）。その後、プッシュする。
  5. リモートとの同期を確認 — 合格条件： git status がクリーンで、git status -sb にブランチが設定済みのアップストリームと同期していることが示されている（このタスクで予期しない未プッシュのコミットが残っていない）。

ステップ 1：コンテキストを把握する

変更内容を理解するため、これらのコマンドを並行して実行します。

# See all untracked and modified files
git status

# See staged and unstaged changes
git diff
git diff --cached

# See recent commit messages for style reference
git log --oneline -10

ステップ 2：変更を分析する

変更を確認し、以下を判断します。

  • 種類：どのような種類の変更ですか？

    • feat - 新機能または新しい機能の追加
    • fix - バグ修正
    • docs - ドキュメントのみの変更
    • refactor - 動作を変えないコードの再構成
    • test - テストの追加または更新
    • chore - メンテナンス、依存関係の更新
    • perf - パフォーマンスの改善
    • ci - CI/CD の変更

  • スコープ：どのコンポーネントに影響しますか？

    • 変更されたファイルを調べ、適切なスコープを判断します
    • プロジェクト内で一貫したスコープ名を使用します（パターンは git log で確認します）
    • (複数の領域にまたがる変更ではスコープを省略します)

  • 破壊的変更：後方互換性を損ないますか？損なう場合は、スコープの後に ! を付けます。

ステップ 3：コミットメッセージを書く

形式：

type(scope): description

[optional body explaining why, not what]

[optional footer with issue references]

ルール：

  • 命令形を使います。「added」ではなく「add feature」のようにします
  • 先頭行は 72 文字未満にします
  • 本文では「なぜ」に焦点を当て、差分で「何を」示します
  • イシューを参照します：Closes #123 または Fixes #456

ステップ 4：ステージング、コミット、プッシュを行う

git commit の前にゲート 1〜3 を満たし、git push の前にゲート 4 を満たし、プッシュ後にゲート 5 を満たします。

# Stage all changes (or selectively stage)
git add -A

# Gate 3: confirm staged set before committing
git diff --cached --stat

# Commit with message (use HEREDOC for multi-line)
git commit -m "$(cat <<'EOF'
type(scope): description

Optional body explaining the motivation.

Closes #123
EOF
)"

# Push to remote
git push

例

# Simple feature
git commit -m "feat(api): add pagination support to list endpoints"

# Bug fix with body
git commit -m "$(cat <<'EOF'
fix(auth): handle token expiration during long requests

The previous implementation did not account for tokens expiring
during the processing of long-running requests.

Fixes #42
EOF
)"

# Breaking change
git commit -m "$(cat <<'EOF'
feat!(api): change response format for user endpoints

BREAKING CHANGE: The `status` field is now an object with `state` and
`message` properties instead of a plain string.
EOF
)"

プロジェクトの慣例に応じて、共同作成者またはフッターのトレーラーを任意で追加できます（例：Co-Authored-By: 行や、ツールの帰属を示すフッター）。プロジェクトにそのような慣例がなければ省略してください。

ステップ 5：確認する

プッシュ後にゲート 5 を満たすため、git status と git status -sb を実行し、作業ツリーがクリーンでアップストリームと同期していることを確認します（フォークのワークフローなど、想定内で説明できる ahead/behind の場合は除きます）。

コメント

Markdown 対応