Git Commit Helper

クイックスタート

ステージされた変更を分析してコミットメッセージを生成します:

# ステージされた変更を確認
git diff --staged

# 変更に基づいてコミットメッセージを生成
# (Claude が diff を分析し、メッセージを提案します)

コミットメッセージのフォーマット

Conventional Commits フォーマットに従います:

<type>(<scope>): <description>

[オプション: 本文]

[オプション: フッター]

タイプ

• feat: 新機能
• fix: バグ修正
• docs: ドキュメント変更
• style: コードスタイルの変更 (フォーマット、セミコロン欠落など)
• refactor: コードリファクタリング
• test: テストの追加または更新
• chore: メンテナンスタスク

例

機能のコミット:

feat(auth): add JWT authentication

Implement JWT-based authentication system with:
- Login endpoint with token generation
- Token validation middleware
- Refresh token support

バグ修正:

fix(api): handle null values in user profile

Prevent crashes when user profile fields are null.
Add null checks before accessing nested properties.

リファクタリング:

refactor(database): simplify query builder

Extract common query patterns into reusable functions.
Reduce code duplication in database layer.

変更の分析

コミットされる内容を確認します:

# 変更されたファイルを表示
git status

# 詳細な変更を表示
git diff --staged

# 統計情報を表示
git diff --staged --stat

# 特定のファイルの変更を表示
git diff --staged path/to/file

コミットメッセージのガイドライン

すべきこと:

• 命令形で書く (「added feature」ではなく「add feature」)
• 最初の行を50文字以内にする
• 最初の文字を大文字にする
• 概要の最後にピリオドをつけない
• 本文では「何」だけでなく「なぜ」を説明する

すべきではないこと:

• 「update」や「fix stuff」のような曖昧なメッセージを使う
• 概要に技術的な実装詳細を含める
• 概要行に段落を書く
• 過去形を使う

複数ファイルのコミット

複数の関連変更をコミットする場合:

refactor(core): restructure authentication module

- Move auth logic from controllers to service layer
- Extract validation into separate validators
- Update tests to use new structure
- Add integration tests for auth flow

Breaking change: Auth service now requires config object

スコープの例

フロントエンド:

• feat(ui): add loading spinner to dashboard
• fix(form): validate email format

バックエンド:

• feat(api): add user profile endpoint
• fix(db): resolve connection pool leak

インフラストラクチャ:

• chore(ci): update Node version to 20
• feat(docker): add multi-stage build

破壊的変更

破壊的変更を明確に示します:

feat(api)!: restructure API response format

BREAKING CHANGE: All API responses now follow JSON:API spec

Previous format:
{ "data": {...}, "status": "ok" }

New format:
{ "data": {...}, "meta": {...} }

Migration guide: Update client code to handle new response structure

テンプレートワークフロー

1. 変更を確認: git diff --staged
2. タイプを特定: feat、fix、refactor など、どれか?
3. スコープを決定: コードベースのどの部分?
4. 概要を作成: 簡潔で命令形の説明
5. 本文を追加: なぜか、何の影響があるかを説明
6. 破壊的変更を記載: 該当する場合

インタラクティブなコミットヘルパー

git add -p で選択的にステージします:

# インタラクティブにステージ
git add -p

# ステージされた内容を確認
git diff --staged

# メッセージでコミット
git commit -m "type(scope): description"

コミットの修正

最後のコミットメッセージを修正します:

# コミットメッセージのみを修正
git commit --amend

# 修正し、さらに変更を追加
git add forgotten-file.js
git commit --amend --no-edit

ベストプラクティス

1. アトミックなコミット - コミットごとに1つの論理的な変更
2. コミット前にテスト - コードが動作することを確認
3. Issue を参照 - 該当する場合は Issue 番号を含める
4. フォーカスを保つ - 無関連な変更を混ぜない
5. 人間向けに書く - 将来の自分がこれを読むことになります

コミットメッセージチェックリスト

• タイプが適切か (feat/fix/docs など)
• スコープが具体的で明確か
• 概要が50文字以内か
• 概要が命令形か
• 本文が「何」だけでなく「なぜ」を説明しているか
• 破壊的変更が明確にマークされているか
• 関連する Issue 番号が含まれているか