Enforcing Git Commit Workflow

意味のあるコミット履歴を保つための厳格なGitワークフロー管理スキル。

いつ使うか

• コードをコミットする時
• ユーザーがgit関連の操作を要求した時
• コミットメッセージの作成が必要な時

基本原則

1. 機能別コミットを原則とする

各コミットは1つの明確な目的を持つこと。

2.

git add -A

禁止

例外:

pnpx changeset version

が生成した大量のパッケージ更新を commit する場合のみ。

3. 必ず個別ステージング

# ✅ 正しい
git add path/to/changed-file.ts
git add another/file.test.ts
git commit -m "test: add edge-case tests for suggest command"

# ❌ 間違い
git add -A
git commit -m "update files"

Prefix 一覧

詳細は prefix-reference.md を参照。

主要なPrefix

Prefix	用途 (日本語)	説明
fix	バグ修正	コードの不具合を修正するコミット
hotfix	クリティカルなバグ修正	サービス停止レベルの緊急バグ対応
add	新規機能追加	新しいファイルや小規模機能を追加するコミット
feat	新機能	ユーザー向けの大きな機能追加または変更
update	機能修正	既存機能に対する修正・改善（バグ修正ではない）
change	仕様変更	仕様そのものを変更するコミット
clean	整理	使われていないコードの削除や軽微な整理
disable	無効化	機能を一時的に無効化（コメントアウト等）
refactor	リファクタリング	挙動を変えずに内部構造のみ改善
remove	削除	ファイル・ライブラリ・機能を削除するコミット
upgrade	バージョンアップ	依存ライブラリや FW のメジャーアップデート
revert	変更取り消し	以前のコミットを打ち消すコミット
docs	ドキュメント	README やコメントのみの変更
style	スタイル修正	コードフォーマット、空白、セミコロンなど動作に影響しない変更
perf	パフォーマンス	パフォーマンス改善のための実装変更
test	テスト	テストコードの追加・更新・リファクタ
chore	雑多メンテ	ビルド、CI、依存更新など本番コードに影響しない作業

実行フロー

ステップ1: ファイル分類

変更ファイルを目的別にグループ化：

• テストコード
• 実装コード
• ドキュメント
• 設定ファイル

ステップ2: 個別ステージング

# テストを先にコミット
git add src/__tests__/feature.test.ts
git commit -m "test: add tests for new feature"

# 次に実装
git add src/feature.ts
git commit -m "feat: implement new feature"

ステップ3: 不明点の確認

判断できない場合は必ずユーザーに確認：

• 「この変更はどのカテゴリに属しますか？」
• 「これらのファイルは一緒にコミットして良いですか？」

警告・中断処理

以下を検出した場合、警告を表示し処理を中断：

• git add -A

  の使用（例外: changeset version）
• 不明確なコミットメッセージ
• 複数の目的が混在するコミット

ユーザーが強制実行を指定しない限り続行しない。

自動コミット禁止

Claude Code 自身が判断して Push まで行う場合でも、上記手順に従ってログを分割すること。

参考

詳細なPrefix一覧とガイドラインは prefix-reference.md を参照。