gh-commit

スマート Git コミット

整ったコミットを作成します：$ARGUMENTS

現在のリポジトリの状態

• Git の状態：!git status --porcelain
• 現在のブランチ：!git branch --show-current
• ステージ済みの変更：!git diff --cached --stat
• ステージされていない変更：!git diff --stat
• 最近のコミット：!git log --oneline -5

このコマンドの動作

1. git status でステージされているファイルを確認します
2. ステージされているファイルが 0 件の場合、変更されたファイルと新しいファイルをすべて git add で自動的に追加します
3. git diff を実行して、コミットする変更内容を把握します
4. 差分を分析し、異なる論理的な変更が複数含まれているかを判断します
5. 異なる変更が複数検出された場合、コミットを複数の小さなコミットに分割することを提案します
6. 各コミット（分割しない場合は単一のコミット）について、Conventional Commits 形式でコミットメッセージを作成します

コミットのベストプラクティス

• 以下に説明する Conventional Commits の仕様に従ってください。

Conventional Commits 1.0.0

概要

Conventional Commits の仕様は、コミットメッセージに関する軽量な規約です。明確なコミット履歴を作成するための簡単なルールを定めており、その上に自動化ツールを構築しやすくします。この規約は、コミットメッセージで機能、修正、破壊的変更を説明することで、SemVer と連携します。

コミットメッセージは、次のような構成にします。

<type>[optional scope]: <description>

[optional body]

[optional footer(s)]

コミットには、ライブラリの利用者に意図を伝えるため、次の構成要素を含めます。

1. fix： type が fix のコミットは、コードベースのバグを修正します（セマンティックバージョニングの PATCH に相当します）。
2. feat： type が feat のコミットは、コードベースに新機能を追加します（セマンティックバージョニングの MINOR に相当します）。
3. BREAKING CHANGE： BREAKING CHANGE: フッターを含むコミット、または type／scope の後に '!' を付けたコミットは、API に破壊的変更を加えます（セマンティックバージョニングの MAJOR に相当します）。BREAKING CHANGE は、どの type のコミットにも含められます。
4. fix: と feat: 以外の type も使用できます。たとえば、@commitlint/config-conventional は、Angular の規約に基づき、build:、chore:、ci:、docs:、style:、refactor:、perf:、test: などを推奨しています。
5. BREAKING CHANGE: <description> 以外の フッター も追加でき、git trailer format と同様の規約に従います。

Conventional Commits の仕様では追加の type を必須としておらず、Semantic Versioning において暗黙の効果はありません（BREAKING CHANGE を含む場合を除きます）。追加のコンテキスト情報を示すため、コミットの type に scope を指定できます。scope は丸括弧で囲みます。例：feat(parser): add ability to parse arrays

例

説明と破壊的変更のフッターを含むコミットメッセージ

feat: allow provided config object to extend other configs

BREAKING CHANGE: `extends` key in config file is now used for extending other config files

破壊的変更を目立たせるために '!' を使ったコミットメッセージ

feat'!': send an email to the customer when a product is shipped

scope と '!' を使って破壊的変更を目立たせるコミットメッセージ

feat(api)'!': send an email to the customer when a product is shipped

'!' と BREAKING CHANGE フッターの両方を含むコミットメッセージ

chore'!': drop support for Node 6

BREAKING CHANGE: use JavaScript features not available in Node 6.

本文のないコミットメッセージ

docs: correct spelling of CHANGELOG

scope を含むコミットメッセージ

feat(lang): add Polish language

複数段落の本文と複数のフッターを含むコミットメッセージ

fix: prevent racing of requests

Introduce a request id and a reference to latest request. Dismiss
incoming responses other than from latest request.

Remove timeouts which were used to mitigate the racing issue but are
obsolete now.

Reviewed-by: Z
Refs: #123

仕様

この文書におけるキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、「OPTIONAL」は、RFC 2119で説明されているとおりに解釈してください。

1. コミットには、名詞であるタイプ（feat、fixなど）を必ず先頭に付け、その後に任意のスコープ、任意の'!'、必須の末尾のコロンとスペースを続けてください。
2. コミットによってアプリケーションまたはライブラリに新機能が追加される場合、タイプには必ずfeatを使用してください。
3. コミットがアプリケーションのバグ修正を表す場合、タイプには必ずfixを使用してください。
4. タイプの後にスコープを指定してもかまいません。スコープは、コードベースのセクションを表す名詞を括弧で囲んだものにしてください（例：fix(parser):）。
5. 説明は、タイプ／スコープのプレフィックスに続くコロンとスペースの直後に置いてください。説明はコード変更を簡潔に要約したものです（例：fix: 文字列に複数のスペースが含まれる場合の配列の解析に関する問題を修正）。
6. 簡潔な説明の後に、コード変更についての追加情報を含む、より長いコミット本文を記載してもかまいません。本文は説明の後に空行を1行挟んで開始してください。
7. コミット本文の形式は自由で、改行で区切られた段落をいくつでも含めることができます。
8. 本文の後に空行を1行挟んで、1つ以上のフッターを記載してもかまいません。各フッターは、単語トークン、:<space>または<space>#の区切り文字、文字列値の順で構成してください（これはgit trailer conventionに基づいています）。
9. フッターのトークンでは、空白文字の代わりに-を使用してください（例：Acked-by）。これにより、フッターのセクションと複数段落の本文を区別しやすくなります。ただし、例外としてBREAKING CHANGEもトークンとして使用できます。
10. フッターの値にはスペースや改行を含めてもかまいません。次の有効なフッターのトークンと区切り文字のペアが検出された時点で、解析を終了してください。
11. 破壊的変更は、コミットのタイプ／スコープのプレフィックス、またはフッターの項目として必ず示してください。
12. フッターとして含める場合、破壊的変更は大文字のテキストBREAKING CHANGEに続けてコロン、スペース、説明を記載してください（例：BREAKING CHANGE: 環境変数が設定ファイルより優先されるようになりました）。
13. タイプ／スコープのプレフィックスに含める場合、破壊的変更は:の直前に'!'を付けて示してください。'!'を使用する場合、フッターセクションのBREAKING CHANGE:は省略してもかまいません。その場合、コミットの説明で破壊的変更を記述してください。
14. コミットメッセージでは、featとfix以外のタイプも使用できます（例：docs: リファレンスドキュメントを更新）。
15. Conventional Commitsを構成する情報単位は、実装者によって大文字と小文字を区別せずに扱われなければなりません。ただし、例外としてBREAKING CHANGEは必ず大文字にしてください。
16. フッターのトークンとして使用する場合、BREAKING-CHANGEはBREAKING CHANGEと同義でなければなりません。

Conventional Commitsを使用する理由

• CHANGELOGを自動生成できます。
• セマンティックバージョンの変更（取り込まれたコミットのタイプに基づく）を自動的に判定できます。
• チームメイト、一般の人々、その他の関係者に変更内容を伝えられます。
• ビルドと公開のプロセスを開始できます。
• より体系化されたコミット履歴を確認できるようになり、プロジェクトへの貢献が容易になります。

FAQ

初期開発段階のコミットメッセージはどうすればよいですか？

製品をすでにリリースしたかのように進めることをおすすめします。通常、ソフトウェアを利用しているのは、たとえ同じソフトウェア開発者であっても、誰かしらいます。その人たちは、何が修正され、何が壊れるのかなどを知りたいと考えています。

コミットタイトルのタイプは大文字ですか、小文字ですか？

大文字と小文字のどちらも使用できますが、統一するのが最善です。

コミットが複数のコミットタイプに該当する場合はどうすればよいですか？

可能であれば、戻って複数のコミットに分けてください。Conventional Commits のメリットの一つは、より整理されたコミットや PR を作成するよう促してくれることです。

これは迅速な開発や素早い反復を妨げませんか？

整理されていない方法で急いで進めることを妨げます。さまざまな貢献者が関わる複数のプロジェクトにおいて、長期的に迅速な開発を続けられるように支援します。

Conventional Commits によって、開発者が定義済みのタイプを意識し、作成するコミットの種類を制限してしまう可能性はありますか？

Conventional Commits は、fix のような特定のタイプのコミットをより多く作成するよう促します。それ以外については、Conventional Commits の柔軟性により、チーム独自のタイプを作成し、時間の経過に応じて変更できます。

SemVer とはどのように関係していますか？

fix タイプのコミットは PATCH リリースに、feat タイプのコミットは MINOR リリースに対応させます。タイプにかかわらず、コミットに BREAKING CHANGE が含まれる場合は MAJOR リリースに対応させます。

@jameswomack/conventional-commit-spec のような Conventional Commits 仕様の拡張機能には、どのようにバージョンを付ければよいですか？

この仕様の独自の拡張機能をリリースする際は、SemVer を使用することをおすすめします（また、こうした拡張機能の作成を推奨しています！）

誤って間違ったコミットタイプを使った場合はどうすればよいですか？

仕様にあるタイプを使ったものの、正しいタイプではなかった場合。例：feat の代わりに fix を使った場合

間違いをマージまたはリリースする前に、git rebase -i を使ってコミット履歴を編集することをおすすめします。リリース後の修正方法は、使用しているツールやプロセスによって異なります。

仕様にないタイプを使った場合。例：feat の代わりに feet を使った場合

最悪の場合でも、Conventional Commits 仕様に準拠していないコミットが取り込まれても、世界の終わりではありません。そのコミットが仕様に基づくツールで検出されなくなるだけです。

すべての貢献者が Conventional Commits 仕様を使う必要がありますか？

いいえ！Git のスカッシュベースのワークフローを使っている場合、リードメンテナーはマージ時にコミットメッセージを整理できるため、気軽にコミットする人の作業負担は増えません。よく使われるワークフローの一つは、プルリクエストのコミットを Git システムで自動的にスカッシュし、リードメンテナーがマージ用の適切な Git コミットメッセージを入力できるフォームを表示する方法です。

Conventional Commits ではリバートコミットをどのように扱いますか？

コードのリバートは複雑になることがあります。複数のコミットをリバートするのでしょうか？機能をリバートした場合、次のリリースはパッチにするべきでしょうか？

Conventional Commits では、リバートの動作を明示的に定義しようとはしていません。代わりに、リバートを処理するロジックの開発には、ツールの作者が types と footers の柔軟性を活用できるようにしています。

一つの推奨方法は、revert タイプと、リバート対象のコミット SHA を参照するフッターを使うことです。

revert: let us never again speak of the noodle incident

Refs: 676104e, a215868

AI 支援コードの著者情報の明記

AI ツールを使ってコードを生成する際、説明責任、コードレビュー、監査のために、著者情報の透明性を保つと有益です。コミットメッセージの末尾に構造化されたメタデータを追加する Git トレーラーを使えば、簡単に対応できます。

コミットメッセージに、次のようなカスタムトレーラーを 1 つ以上追加します。

Assistant-model: Claude Code

多くの Git ツールでは、Co-authored-by トレーラーはメールアドレス形式であることが想定されています。混乱を避け、著者情報と支援情報を区別するため、別のトレーラーキーを使ってください。

トレーラーはコミットメッセージの末尾に手動で追加することも、--trailer オプションを指定した git commit コマンドで追加することもできます。

git commit --message "Implement feature" --trailer "Assistant-model: Claude Code"

git log コマンドの pretty formats オプションを使うと、トレーラーを表示できます。たとえば、各コミットのハッシュ、著者名、使用したアシスタントモデルを表示する履歴は、次のように整形できます。

git log --color --pretty=format:"%C(yellow)%h%C(reset) %C(blue)%an%C(reset) [%C(magenta)%(trailers:key=Assistant-model,valueonly=true,separator=%x2C)%C(reset)] %s%C(bold cyan)%d%C(reset)"

2100e6c Author [Claude Code] Test commit 4 (HEAD -> work-item-8)
7120221 Author [Claude Code] Test commit 3
ea03d91 Author [] Test commit 2
f93fd8e Author [Claude Code] Test commit 1
dde0159 Claude Code [] Test work item (#7) (origin/main, origin/HEAD)

重要な注意事項

• デフォルトでは、コード品質を確認するために、（prek.toml で定義された）pre-commit チェックが実行されます
  • 重要：pre-commit チェックをスキップしないでください
• AI 支援コードの著者情報を必ず明記してください
• 特定のファイルがすでにステージングされている場合、コマンドはそのファイルのみをコミットします
• ステージングされたファイルがない場合、変更されたファイルと新しいファイルがすべて自動的にステージングされます
• 検出された変更に基づいて、コミットメッセージが作成されます
• コミット前に差分を確認し、複数のコミットに分けるほうが適切かどうかを判断します
• 複数のコミットが提案された場合、変更を個別にステージングしてコミットできるよう支援します
• コミットメッセージが変更内容に合っているか、コミットの差分を必ず確認します