Conventional Commitsリンター
コミットメッセージをConventional Commits仕様に照らして検証します。タイプ、スコープ、説明、本文形式をチェックします。
このツールについて
Conventional Commitsリンターは、Gitコミットメッセージを Conventional Commits仕様に 照らして検証する無料のブラウザベースツールです。Conventional Commitsは コミットメッセージの上に軽量な規約を加えたもので、構造化された形式を 提供します:タイプ、オプションのスコープ、説明、 オプションの本文、オプションのフッター。この構造により コミット履歴が読みやすくなり、変更ログの自動生成が可能になり、 セマンティックバージョニングとの統合がスムーズになります。
このリンターは各コミットメッセージを解析し、設定可能なルールセットに
照らしてチェックします。コミットが認識されたタイプ(feat、fix、
docs、choreなど)で始まっているか、オプションのスコープが
括弧で囲まれているか、タイプの後にコロンとスペースが続いているか、
説明が空でないかを検証します。また、件名行の長さ(デフォルト最大72文字)、
本文行の長さ(最大100文字)、破壊的変更マーカー(!または
BREAKING CHANGEフッター)、フッター形式(key: valueまたは
key #value)もチェックします。
プロジェクトのニーズに合わせてツールをカスタマイズできます。標準セット
以外のカスタムコミットタイプを追加したり、スライダーで件名行の最大長を
調整したり、個々のルールを有効・無効にできます。一括モードでは
---で区切った複数のコミットメッセージを貼り付けて一度に検証でき、
合格・不合格の件数のサマリーが表示されます。
Gitを日常的に使用している方には、 Gitコマンドビルダーで複雑なGitコマンドを 構築したり、.gitignoreジェネレーターで ignoreファイルを作成するのも便利です。コミット前のコード変更を 比較するには、差分ビューアーをお試しください。
すべての処理はブラウザ内で完結します。コミットメッセージがサーバーに 送信されることはありません。APIコール、ログ記録、サードパーティ サービスの関与はありません。内部プロジェクト名やチケット参照など 機密情報を含むコミットメッセージでも安全に検証できます。
使い方
- 左側のコミットメッセージテキストエリアに1つ以上のコミットメッセージを貼り付けます。
- 右パネルでリアルタイムの検証結果を確認します。各ルールに緑のチェック、赤のX、黄色の警告が表示されます。
- 複数のコミットを一度に検証するには、
---行で区切ります。合格・不合格の件数を示す一括サマリーが表示されます。 - Optionsをクリックして設定パネルを展開します。件名行の最大長スライダー(デフォルト72)を調整します。
- カスタム許可タイプにカンマ区切りの値(例:
wip, hotfix, release)を入力して、デフォルトのタイプリストを拡張します。 - ルールの有効化・無効化のチェックボックスで個々のルールを切り替えます。
- 修正候補がある場合はCopy correctedをクリックして自動修正されたメッセージをコピーします。Ctrl+Shift+Cで元の入力をコピーできます。
Conventional Commitsの代表例
よくある質問
Conventional Commits仕様とは何ですか?
Conventional Commitsは、コミットメッセージに人間と機械が読み取れる意味を付加するための仕様です。`type(scope): description`という構造化された形式を定義し、オプションの本文とフッターが続きます。標準タイプにはfeat、fix、docs、style、refactor、perf、test、build、ci、chore、revertがあります。この規約により、自動ツールが変更ログを生成し、セマンティックバージョンのバンプを決定し、変更の性質を他の開発者に伝えることができます。
デフォルトで許可されているタイプは何ですか?
デフォルトの許可タイプは:feat、fix、docs、style、refactor、perf、test、build、ci、chore、revertです。Optionsパネルでカンマ区切りの値(例:wip、hotfix、release)を入力してカスタムタイプを追加できます。カスタムタイプはデフォルトリストに追加されます。
破壊的変更はどのように示しますか?
Conventional Commitsで破壊的変更を示す方法は2つあります。1つ目は、タイプ/スコープの後、コロンの前に`!`を付ける方法です(例:`feat!: remove deprecated API`や`feat(api)!: change response format`)。2つ目は、コミット本文に`BREAKING CHANGE: description`フッターを追加する方法です。両方の方法が有効で、併用することもできます。
複数のコミットを一度に検証できますか?
はい。入力テキストエリアに複数のコミットメッセージを貼り付け、`---`行で区切ります。ツールは各コミットを個別に検証し、結果の上部に合格・不合格の合計数を示す一括サマリーを表示します。
推奨される件名行の長さは?
デフォルトの件名行の最大長は72文字で、Gitコミットメッセージの広く受け入れられた規約です。この制限により、ターミナル出力、GitHub、その他のGitツールでコミットメッセージが適切に表示されます。Optionsパネルのスライダーでこの制限を50〜120文字の範囲で調整できます。
データは安全ですか?
はい。すべての検証はJavaScriptを使用してブラウザ内で完全に実行されます。コミットメッセージがサーバーに送信されることはありません。ツール使用中にブラウザの開発者ツールのネットワークタブで確認できます。内部プロジェクト名、チケット参照、その他の機密情報を含むコミットの検証でも安全に使用できます。
どのフッター形式に対応していますか?
Conventional Commitsは2つのフッター形式をサポートします:`key: value`(例:`Reviewed-by: Alice`)と`key #value`(例:`Refs #123`)。特別なフッター`BREAKING CHANGE: description`は破壊的変更を示すために使用されます。フッター行はコミット本文の後の空行の後に表示されます。
関連ツール
Gitコマンドビルダー
操作、オプション、フラグを選択してGitコマンドを視覚的に構築します。説明付き。
.gitignore生成
言語、フレームワーク、IDEを選択して.gitignoreファイルを生成。複数テンプレートを即座に結合。
差分ビューア
2つのテキストを行単位・文字単位の差分ハイライトで並べて比較します。
正規表現テスター
リアルタイムのマッチハイライトとキャプチャグループで正規表現をテストします。
Gitブランチ名ジェネレーター
チケット番号やタイトルからクリーンなGitブランチ名を生成します。命名規則のカスタマイズ可能。
Changelogジェネレーター
Conventional CommitsからCHANGELOG.mdを生成します。タイプ別グループ化、バージョンヘッダー、Keep a Changelog形式でエクスポート。
Gitコミットメッセージジェネレーター
ビジュアルフォームでConventional Commitsメッセージを生成します。type、scope、description、body、破壊的変更を選択。
Semantic Releaseコンフィグビルダー
semantic-releaseの設定ファイルをビジュアルに生成します。プラグイン選択、ブランチ設定、リリースルール、JSON/YAML/JSエクスポート対応。
CONTRIBUTING.mdジェネレーター
オープンソースプロジェクト向けのプロフェッショナルなCONTRIBUTING.mdファイルをテンプレートから生成します。
リリースノートジェネレーター
バージョン情報と変更エントリからプロフェッショナルなリリースノートを生成します。
Gitコマンドリファレンス
ワークフロー別に整理されたGitコマンドリファレンス。検索、逆引き、ワークフロー図、コマンドコピー機能付き。