Git Commit Helper

Git Commit Helper

クイックスタート

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

# View staged changes
git diff --staged

# Generate commit message based on changes
# (Claude will analyze the diff and suggest a message)

コミットメッセージの形式

Conventional Commits の形式に従います:

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

[optional body]

[optional footer]

タイプ

• 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.

変更の分析

コミット対象の内容を確認します:

# Show files changed
git status

# Show detailed changes
git diff --staged

# Show statistics
git diff --staged --stat

# Show changes for specific file
git diff --staged path/to/file

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

推奨:

• 命令形を使用する（「added feature」ではなく「add feature」）
• 1行目は50文字以内にする
• 先頭の文字は大文字にする
• 要約の末尾にピリオドを付けない
• 本文では WHAT だけでなく WHY を説明する

非推奨:

• 「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 を使うと、部分的にステージできます:

# Stage changes interactively
git add -p

# Review what's staged
git diff --staged

# Commit with message
git commit -m "type(scope): description"

コミットの修正

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

# Amend commit message only
git commit --amend

# Amend and add more changes
git add forgotten-file.js
git commit --amend --no-edit

ベストプラクティス

1. アトミックなコミット - コミットごとに論理的な変更は1つだけにする
2. コミット前にテストする - コードが動作することを確認する
3. Issue を参照する - 該当する場合は Issue 番号を含める
4. 焦点を絞る - 無関係な変更を混ぜない
5. 人が読むことを意識して書く - 将来の自分が読むことになる

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

• タイプが適切である（feat/fix/docs など）
• スコープが具体的で明確である
• 要約が50文字以内である
• 要約が命令形で書かれている
• 本文が WHAT だけでなく WHY を説明している
• 破壊的変更が明確に示されている
• 関連する Issue 番号が含まれている