Conventional Commits メッセージフォーマッタ
タイプ、スコープ、説明からスペック準拠の Conventional Commits メッセージを作成したり、既存のコミットメッセージを貼り付けてその部分に分解したりできます。サブジェクト行の72文字制限を追跡し、自動的に BREAKING CHANGE フッターを追加します。
入力
この変更が影響するコードベースの範囲(オプション)。
命令形での簡潔な説明、末尾にピリオドなし。
出力
| チェック | 結果 |
|---|---|
| No data yet | |
このツールを使う他の方法
REST API
curl -X POST https://api.iotools.cloud/v1/tool/conventional-commit-message-formatter \
-H "Authorization: Bearer YOUR_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"mode": "build",
"type": "feat",
"scope": "auth",
"description": "add OAuth2 login support",
"breaking": "true",
"breakingDescription": "The login() function now requires an options obj…",
"body": "Implements the OAuth2 authorization code flow us…",
"footers": "Refs: #482"
}'ご自身のアカウントのキーに差し替えてください。ツールのフィールドがそのままリクエストボディになります——ラッパーはありません。
AIエージェントに依頼する
Use the IOTools `conventional-commit-message-formatter` tool (Conventional Commit Message Formatter) on this input:
YOUR_INPUT_HEREIOTools MCPサーバーに接続された任意のエージェントにこれを貼り付け、入力内容を追加してください。
埋め込みウィジェット
<iframe
src="https://iotools.cloud/embed/conventional-commit-message-formatter/"
width="100%" height="520" frameborder="0" scrolling="no" loading="lazy"
title="Conventional Commits メッセージフォーマッタ — iotools.cloud"
sandbox="allow-scripts allow-forms allow-same-origin allow-downloads allow-popups allow-popups-to-escape-sandbox"
allow="clipboard-write"
style="width:100%;border:1px solid #e5e7eb;border-radius:12px;overflow:hidden"></iframe>
<script src="https://iotools.cloud/embed.js" async></script>ご自身のページに貼り付けるだけ——無料、キー不要、リンクを掲載するだけです。
| API/MCP 1回あたりの費用 | 5クレジットから |
|---|---|
| クレジットが足りませんか? | 料金を見る |
次の方法でも利用可能
ガイド
Conventional Commitsは、コミットメッセージのための厳密で
機械可読なフォーマットです: type、オプショナルなscope、短い説明、およびオプショナルな本文/フッター
のセクション。commitlint、semantic-release、自動changelog生成ツールなどのツールは
すべてこの正確な形式を解析します — 1文字でも間違っていると(コロンが足りない、スペースが余分、
フッター構文が間違っている)、コミットは静かに検証に失敗するか、changelogからスキップされます。
このツールはフォームからスペック準拠のメッセージを生成するため、形式は常に正しく、既存の
メッセージをその部分に逆解析することもできます。すべてブラウザで実行されます。
使い方
- メッセージを作成を選択します。
- タイプ(
feat、fix、docsなど)を選択し、必要に応じてスコープ (影響を受けるコードベースの領域、例:apiまたはparser)を選択します。 - 命令形で短い説明を書きます(「追加」、「追加した」ではなく)。
- コミットが後方互換性を破壊する場合は破壊的な変更をチェックし、
破壊について説明してください — スペックで要求されているとおり、
タイプ/スコープの後に
BREAKING CHANGE:フッターと!として追加されます。 - より詳細な説明のためにオプショナルな本文を追加し、
Refs: #123やReviewed-by: Nameなどのフッター(1行に1つ)を追加します。 - フォーマットされたメッセージを
git commit -m "..."またはエディタの コミットメッセージボックスに直接コピーします。
メッセージを解析に切り替えて逆の操作を行います: 既存のコミットメッセージを貼り付けると、 ツールはそれをタイプ、スコープ、破壊的変更フラグ、説明、本文、フッターに逆解析します — 他の人が書いたメッセージが実際にスペックに従っているかを確認するのに便利です。
サブジェクト行の長さ
Subject Checkテーブルは、フォーマットされたヘッダー(type(scope)!: description)を
一般的に使用される72文字の制限に対して追跡するため、git log --onelineやGitHubの
コミットリストで切り詰められる長いサブジェクト行がコミット前に捕捉されます。
コミットタイプ
featとfixは、semantic-releaseなどのツールが履歴を読むときに
Semantic Versioningのセマンティックバージョンのbumpに直接対応し、
BREAKING CHANGEフッター(または!)はタイプに関係なくメジャーbumpをトリガーします。
残り — docs、style、refactor、perf、test、chore、ci、build、revert —
はバージョン番号に影響を与えずに変更を説明します。
これはcommitlintのようなコミットフックに代わるものですか?
いいえ — commitlintはコミット時(通常はGitフック経由で)コミットを検証し、 チームのワークフローで自動的に実行することを意図しています。このツールは 1つのメッセージを手書きするか、メッセージを貼り付ける前にチェックするためのものです。 両方を使用してください: これはメッセージを作成し、commitlintは自動的にルールを適用します。
1つのメッセージではなく、コミット履歴全体をレビューする必要がある場合はどうすればよいですか?
Git Log Formatter / Prettifierを使用して、
git logの出力をテーブル、リスト、またはJSONに変換するか、
Git Cheatsheetを使用して一般的なGitコマンドを参照してください。