ce-commit

Git コミット

現在の作業ツリーから、適切に作成されたローカルコミットを作成します。プッシュや PR は行いません。フルのリリースフローには ce-commit-push-pr を使用してください。

完了条件： 論理的な変更ごとに、明示的なファイル一覧と変更の成果を示すメッセージを付けてコミットし、git status でそれらの変更がクリーンになっていること。停止条件： 作業ツリーがクリーンであること（コミット対象がないこと）。

コンテキスト

各コマンドは、それぞれ個別のシェルツール呼び出しとして実行して、コンテキストを収集します（プログラムと引数のみ）。;、&&、||、パイプ、$(...)、リダイレクトでコマンドを結合しないでください。Windows PowerShell ではこれらの構文が失敗します。ゼロ以外の終了コードは、抑制するエラーではなく、解釈すべき通常の状態です。

コマンド	目的	ゼロ以外／空の場合
git status	作業ツリーの状態	Git リポジトリではありません。停止してください
git diff HEAD	未コミットの変更	新規リポジトリ／コミットがまだありません
git branch --show-current	現在のブランチ	空 = detached HEAD
git log --oneline -10	最近のメッセージのスタイル	新規リポジトリ — 履歴がありません
git rev-parse --abbrev-ref origin/HEAD	リモートのデフォルトブランチ	origin/HEAD がない／HEAD が bare — gh repo view --json defaultBranchRef --jq '.defaultBranchRef.name' を試し、それも失敗した場合は main

この情報はスナップショットとして扱います。状況が変わった可能性がある場合は、コミット直前にブランチとステージ済みファイルの一覧を再確認してください。

デフォルトブランチ名： origin/HEAD から先頭の origin/ を取り除きます（origin/trunk → trunk）。「デフォルトブランチ上かどうか」の確認には、そのブランチ名のみを使用してください。origin/<name> とは比較しないでください。

ワークフロー

0. 収集 — 上記のコンテキストにあるコマンドをすべて実行します（それぞれ別々のシェル呼び出しで）。その後、次に進みます。

1. コミット対象なし — git status にステージ済み、変更済み、未追跡のファイルがない場合は、その旨を報告して終了します。クリーンな状態の確認に git diff HEAD だけを使わないでください（未追跡ファイルが検出されません）。

2. 最初にブランチを作成 — HEAD がデタッチ状態の場合、またはデフォルトブランチ（main／master／上記のベアなデフォルト名）にいる場合は、変更内容に基づいてフィーチャーブランチを作成し（git checkout -b <name>）、その後 git branch --show-current を再実行します。確認を求めないでください。コミットのみの場合でも、変更をデタッチ状態の HEAD やデフォルトブランチに残してはいけません。派生した名前がすでに存在する場合は、競合しない接尾辞を付けてください。

3. 規約 — コンテキストにあるプロジェクトのコミット規約に従います。ない場合は、直近のログのパターンに従います。それもない場合は、Conventional Commits（type(scope): description）に従います。Conventional Commits を使い、fix と feat のどちらも当てはまる場合は、デフォルトで fix: を使います（壊れている、または欠けている動作を修正する場合）。新しい機能には feat: を使います。ユーザーからの指定があれば、そちらを優先します。

4. 論理単位でコミット — 変更されたファイルが明確に別々の関心事に分かれる場合は、別々にコミットします（ファイル単位のみ、最大2～3件。git add -p は使用しないでください）。判断が難しい場合は、1件のコミットにまとめます。

5. メッセージ — 件名は命令形で、ファイル一覧ではなく、達成される結果（何ができるようになるか、何が修正されるか）を示します。件名だけでは動機やトレードオフが明らかでない場合に限り、本文を付けます。このコミットに対応する Implementation Unit の ID がすでに分かっている場合（会話、呼び出し元、またはファイルが1つのユニットに属する場合）は、そのユニットの U-ID を括弧で末尾に付けます。(U3) はユニット3を意味します。プランを探し回らないでください。複数のユニットにまたがる場合、ユニットが不明確な場合、またはプランが手元にない場合は省略します。自分以外の作業をコミットに含め、その作業が他の人の名前で記録されない場合（他の人のブランチや PR から移植したもの、または他の人のパッチを適用したもの）は、その作業に貢献した各人について、Co-authored-by: Name <email> トレーラーを末尾に付けます。対象には、そのコミットの作成者と、コミットに記載された Co-authored-by トレーラーの人物が含まれます。各ユーザー情報は、該当するコミットまたはパッチから正確にコピーしてください。メールアドレスを推測してはいけません。記録されていない場合は、メッセージ本文に名前を記載します。

   • 悪い例：Update checkout.rb／Add tests and fix stuff
   • 良い例：Fix double-submit on checkout
   • 良い例：Add per-subscription mute (U3)

6. ステージしてコミット — 名前を指定したファイルのみをステージします（git add -A や git add . は使用しないでください）。呼び出しに exclude:<paths> が含まれる場合は、それらのファイルを必ず除外し、変更があってもコミットしません。報告では、除外したファイルをコミットしなかったことを伝えます。ファイル書き込みツールを使い、リポジトリの外にメッセージ全体（件名、空行、必要に応じて本文）を書き出してから、コミットグループごとに次の2つの呼び出しでステージとコミットを行います。

git add file1 file2 file3

git commit -F <message-file> -- file1 file2 file3

メッセージの解析に -F を使うシェルコマンドは使用しません。$、引用符、バッククォート、複数行の本文は、シェルの種類や引用規則にかかわらず、そのまま渡されます。Git の通常の空白処理（末尾の空白の削除、連続する空行のまとめ）は適用されますが、問題ありません。

git commit の末尾にパス一覧を指定する必要があります。パスを指定しない git commit はインデックス全体をコミットするため、実行前からステージされていたファイル（呼び出し元の exclude: 対象や、ユーザーがステージしてファイル名を指定しなかった作業）までコミットに含まれてしまいます。パスを指定すれば、そのグループのファイルだけをコミットし、インデックスの他のエントリはそのまま残せます。

7. 確認 — git status を実行し、ハッシュと件名を報告します。