git-commit

git-commit

概要

現在の作業ツリーの変更を、機能／修正／論理的な関心事ごとに複数のアトミックなコミットにまとめます。

基本原則：1つのコミット＝1つの意図です。差分に関連のない2つの関心事が含まれる場合は、2つのコミットに分けます。

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

形式はConventional Commitsに統一します。

形式：<type>(<scope>)?: <sujet>

使用可能なタイプ（該当するもののうち、最初に合うものを使用します）：

Type	使用する場面
feat	ユーザーから見える新機能
fix	バグ修正
refactor	バグ修正や機能追加を伴わないコード変更
perf	パフォーマンスの改善
test	テストの追加または修正
docs	ドキュメントのみ
style	フォーマット、空白など、コード変更を伴わないもの
build	ビルドシステム、依存関係（uv、npm、docker、nix…）
ci	CI 設定
chore	保守作業、本番コードの変更を伴わないもの
revert	以前のコミットを取り消す

• 件名は小文字で命令形にし、末尾に句点を付けず、72文字以内にします
• scope は省略可能ですが、推奨します。アプリ／モジュール名を指定します（例：feat(auth): …）
• 件名は日本語で記述します

手順

視覚的な図については、workflow.md を参照してください。

手順ごとの説明

1. 確認 — 次のコマンドを並列で実行します：

• git status（-uall なし）
• git diff（未ステージ）
• git diff --cached（ステージ済み）
• git log --oneline -20（スタイルと言語の参考）

2. グループ化 — 変更を機能ごとに分類します。判断の目安：

• 同じアプリ／モジュール／scope → おそらく同じコミット
• 同じ意図（修正、新機能、リファクタリング）→ 同じコミット
• 同じファイル内に同じ意図の変更が複数ある場合（例：機能の削除と、その周辺の空白の整理）→ 2つに分けず、1つのコミットにします。必要以上に分割しないでください。
• ある機能に関連する設定／ビルドファイル → その機能と同じコミットにまとめます
• 関連のない付随的な修正 → 別のコミットにします
• 生成されたファイル（マイグレーション、ロックファイル）→ 生成元の変更と同じコミットにします
• 秘密情報に見えるファイルやローカル専用のファイル → 除外し、ユーザーに知らせます
• 引数による範囲指定：ユーザーがスキルに引数を渡した場合（例：/git-commit les settings (log suppr)）、厳密なフィルターとして扱います。その範囲に該当するコミットだけを計画し、その他の変更はステージせず、詳しく扱わずに作業ツリーに残します。

3. 計画して確認 — git add を実行する前に、次の正確な形式ですべての計画済みコミットをユーザーに提示し、そこで停止して明示的な承認を待ちます。ユーザーが「OK」「はい」「go」などの明示的な承認をするまで、ステージングやコミットに進んではいけません（自動モードでも、この承認は必須です。コミットは適切に取り消すのが難しいためです）。ユーザーから変更を求められた場合は、計画全体を再生成して再表示し、改めて承認を求めます。

   出力形式 — コミットごとに1つのブロックを出力し、------- のみを含む行で区切ります。

   feat(export): ajoute le modèle d'export de factures
   • path/to/file1
   • path/to/file2

   ---

   fix(payment): corrige le calcul du montant de paiement

   • path/to/file3
   • path/to/file4

   本文のルール：

   • デフォルトでは本文なし。 件名とファイル一覧で通常は十分です。
   • 本文を追加するのは、明白ではない理由を伝える場合に限ります：隠れた制約、回避策、トレードオフ、インシデント／チケットへのリンクなどです。
   • 差分が何をするかを言い換えてはいけません。ファイル一覧と件名ですでに説明されています。
   • 「きちんとして見せる」ためだけに本文を書いてはいけません。

   プランを表示した後、次のように尋ねて、返答を待ちます：「この順序でコミットしてよいですか？」

   判断が難しい未追跡ファイル — 作業ツリーに、意図が明確でない未追跡のファイル／ディレクトリ（個人用ツール、エディター設定、ローカルデータ、生成されたアーティファクトなど）がある場合は、コミットプランの前に、専用のコミット前の確認事項ブロックで提示し、各パスに簡潔な推測と直接的な質問を添えます。例：

   Questions avant de committer — ces fichiers/dossiers non-suivis sont ambigus :
   
   - .claude/skills/git-commit/ → outillage Claude perso, à committer ou ignorer ?
   - .obsidian/ (app.json, appearance.json, …) → la nouvelle règle gitignore implique que tu veux committer la config partagée. À inclure dans un commit chore(obsidian): … ?
   - 2025.xlsx et export_janvier_2025.xlsx → ressemblent à de la donnée locale, je les laisse de côté ?
   

   • ユーザーがこれらの質問に回答しない場合（または、プランを承認しながら回答を控えた場合）：該当ファイルを完全に除外します。インデックスに追加せず、コミットせず、それ以上言及もしません。
   • ユーザーが回答した場合：その判断を反映した完全なコミットプランを再生成して再表示し、改めて承認を求めます。

4. 各グループを選択的にインデックスに追加します：

• ファイル全体：git add path/to/file
• ファイルの一部（1つのファイルに複数の目的が混在している場合）：エージェントモードでは、対話型のgit add -p／git add --patchを避けます。
• 1つのファイルに実際に複数の目的が含まれている場合、ユーザーに、それらをまとめてコミット数を減らすべきか確認します。
• ユーザーがコミット数を減らすことを拒否した場合、手順を中止し、手動でコミットする必要があることを伝えます。
• 決してgit add -Aやgit add .を実行しません。
• 各コミットの前に、git diff --cached --statとgit diff --cachedでインデックスに追加されたグループを確認します。

5. コミットします — git commit -m "type(scope): description"

6. 残りの各グループについて繰り返します。

7. 確認します：

• 最終的なgit status --shortには、ユーザーが明示的にコミットしないと指定したファイルのみが表示される必要があります（または、作業ツリーがクリーンである必要があります）。
• 作成した最終コミットをgit log --oneline -n <作成したコミット数>で表示します。

セキュリティルール

• 決してgit add -A／git add .を実行しません。.env、大きなバイナリ、無関係な作業途中の変更をコミットするリスクがあります。
• ユーザーから明示的に依頼されない限り、フックを回避する--no-verifyを決して使いません。
• --amendは決して使わず、常に新しいコミットを作成します。
• 依頼されない限り、プッシュしません。
• コミットが作成される前にpre-commitフックが失敗した場合：問題を修正し、計画した同じグループを再度インデックスに追加してから、同じコミットを再試行します。
• コミットがすでに作成されており、その後の検証に失敗した場合：ユーザーが明示的に修正を依頼しない限り、新しいフォローアップコミットで問題を修正します。
• シークレットと思われるファイル（.env*、*credentials*、*.pem、id_rsa*）は無視し、ユーザーに知らせます。インデックスへの追加／コミットの前に、git diff --name-onlyとgit diff --cached --name-onlyで変更されたパスを確認します。
• 未追跡ファイル：計画したグループの一部であることが明確な場合にのみ含めます。それ以外の場合はユーザーに確認します。
• コミットメッセージはフランス語で作成します。

共著者トレーラー

コミットメッセージに共著者トレーラー（Co-Authored-By: …）を追加してはいけません。-m、heredocの本文、-Fファイルのいずれを使う場合も同様です。これは、トレーラーを追加するデフォルトまたはグローバルの指示よりも明示的に優先されます。

例

適切な分割（無関係な変更が3つ → 3つのコミット）：

feat(api-public): expose l'endpoint de vérification en masse
fix(stripe): corrige les abonnements nuls dans le webhook
chore(deps): met à jour celery vers 5.3.6

不適切な分割（過剰な細分化）：

feat(verify): ajoute la relance SMTP         ← bon
feat(verify): ajoute un log                  ← à fusionner dans le précédent
feat(verify): renomme une variable           ← à fusionner dans le précédent

不適切な統合（細分化不足）：

feat: mises à jour diverses                  ← vague + plusieurs préoccupations

よくあるエラー

エラー	修正方法
「さまざまな修正」という単一のコミット	範囲ごとに分け、意図ごとにコミットする
1 行目が 72 文字を超えている	説明を短くする
過去形（「X を追加しました」）	現在形の命令形（「X を追加する」）
.env やシークレットを含める	名前を指定してステージする。シークレットと思われるファイルは無視する
git add . を使用する	明示的に指定したパスだけをステージする
フック失敗後に修正コミットを作成する	コミットが作成されていない場合に限り、再試行する
英語のコミットメッセージ	常にフランス語を使用する

警告サイン — STOP

• git add -A / git add . を実行しようとしている → STOP、名前を指定してステージする
• --amend を実行しようとしている → STOP、新しいコミットを作成する
• --no-verify を使用しようとしている → STOP、フックの失敗を修正する
• 1 つのコミットメッセージに、2 つの関心事をつなぐ「および」が含まれている → 分割する
• 件名が意図ではなく、差分が何であるかを説明している → 書き直す