mcpField
G
git-commit

git-commit

github.com/onsager-ai開発764 回インストール3 日前に更新
リポジトリ

git-commit について

コミット前の変更を扱う Git 開発者向けのスキルです。Conventional Commits、アトミックな変更、ステージング前の確認、フック失敗時の対応を説明します。

主な機能

  1. 01Conventional Commits 形式
  2. 02論理単位でのアトミックコミット
  3. 03ステージング前の機密情報確認
  4. 04コミットメッセージの作成ルール
  5. 05コミットフック失敗への対応

活用シーン

  1. 01機能や修正のコミットメッセージ作成
  2. 02関連変更を個別のコミットに整理
  3. 03コミット前に認証情報や生成物を確認

インストール

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

$npx skills add https://github.com/onsager-ai/dev-skills --skill git-commit

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

詳細

Git コミット

意図が明確に伝わる、簡潔でアトミックなコミットを作成します。

このスキルを使うとき

以下のいずれかに該当する場合に有効化します。

  • ユーザーが「commit」「make a commit」「stage changes」または「write a commit message」と依頼した
  • ユーザーが「commit my changes」または「commit this」と言った
  • 論理的な作業単位が完了し、反映できる状態になった
  • ユーザーが git add、git commit、または git amend について質問した

決定木

What does the user need?

Stage + commit changes?
  → Check what changed: git status + git diff --staged
  → Group related changes (atomic commit rule below)
  → Write message in conventional format
  → If hook fails: fix root cause, re-stage, new commit

Amend the last commit?
  → ONLY if NOT yet pushed to remote
  → OK for: missing file, minor message fix, small oversight
  → New commit instead: substantial change, already pushed

Write a commit message only?
  → Follow conventional format below
  → Lead with "why", not "what"

Hook failure?
  → Read the full hook output
  → Fix the root cause — never use --no-verify

Conventional Commits の形式

<type>(<scope>): <subject>

<body>      ← optional; explain *why*, not *what*
<footer>    ← optional; breaking changes, refs
種類
TypeWhen
feat新機能または新しい機能の追加
fixバグ修正
refactor動作を変更しないコードの再構成
docsドキュメントのみの変更
testテストの追加または修正
choreビルド、ツール、依存関係の更新
perfパフォーマンスの改善
ciCI/CD ワークフローの変更
ルール
  • 件名:72 文字以内、命令形(「added」ではなく「add」)、末尾にピリオドを付けない
  • 本文:72 文字で折り返し、仕組みではなく動機を説明する
  • 破壊的変更:フッターに BREAKING CHANGE: を記載するか、タイプの後に ! を付ける(feat!:)

アトミックなコミット

1 つのコミットにつき、1 つの論理的な変更を含めます。レビュアーが他のコミットを見なくても内容を理解できるようにします。

まとめるもの: 単一の機能または修正に関するすべてのファイル、そのコードを対象とするテスト。

分けるもの: 動作変更とは別のリファクタリング、無関係な修正、未完了の作業。

「WIP」や「misc fixes」としてコミットしてはいけません。確定前にスカッシュするか、分割してください。

ステージングのチェックリスト

git add の前に、次の点を確認します。

  • シークレット、API キー、認証情報が含まれていない
  • デバッグコードや一時的な回避策(console.log、TODO: remove)が含まれていない
  • 変更内容に関連性がある(1 つの論理的な単位である)
  • .gitignore が守られている — 意図的な場合を除き、ビルド成果物や生成ファイルが含まれていない

例

機能
feat(auth): add OAuth2 login flow

Replaces username/password form. Supports Google and GitHub as providers.
Token refresh is handled automatically by the auth middleware.
バグ修正
fix(publish): handle missing platform binary gracefully

Previously threw unhandled error when the platform package was absent.
Now logs a clear message and exits with code 1.
破壊的変更
feat!: change publish config to support multiple binaries

BREAKING CHANGE: `binary` field renamed to `binaries` array.
Migrate: `binary: 'my-cli'` → `binaries: [{ name: 'my-cli', ... }]`
雑務
chore(deps): upgrade pnpm to 10.6.2

コミット前フックの失敗

  1. フックの出力全体を読みます — 失敗した箇所が正確に示されています
  2. 根本的な問題(lint、型エラー、フォーマット)を修正します
  3. 修正したファイルを再度ステージングします
  4. 新しいコミットを作成します — 失敗した試みを amend してはいけません
  5. ユーザーから明示的に依頼されない限り、--no-verify を使ってはいけません

セットアップと有効化

npx skills add -g onsager-ai/dev-skills --skill git-commit -a claude-code -y

次の場合に自動的に有効化されます:ユーザーが「commit」「stage」「git add」または「commit message」と言ったとき。

コメント