majiayu000 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 を参照。