Git & Version Control

コミットメッセージ生成

項目から作成するか、完成したメッセージを検証します。モードを切り替えても下書きは残ります。

コミットメッセージ生成

メッセージ入力

候補は一般的なタイプです。独自タイプも入力できます。

Refs: #42やCloses #42で始めます。後続の通常行は直前の値の続きです。

メッセージ結果

メッセージはこのブラウザー内で処理します。リポジトリへのアクセスや通信は行いません。

出力オプション

Conventional Commits 1.0.0の構造を検証します。プロジェクト規則や50/72文字の制限は強制しません。最大20,000 UTF-16単位。

説明または完成したメッセージを入力してください。

コミットメッセージ生成は、変更内容は分かっていても、区切りや破壊的変更の書き方に迷う場面で役立ちます。短い要約と背景説明を別々に入力でき、既存の文章は検証モードでそのまま確認できます。作成途中のフォームを消さずに切り替えられるので、手元の草稿と生成結果を落ち着いて見比べられます。

コミットメッセージ生成で構造を見直す

見出しと本文を混ぜない

コミットメッセージ生成ではタイプ、スコープ、要約から先頭行を作り、本文とフッターの前に空行を入れます。本文内の段落は維持されます。コミットメッセージ整形でありがちな、説明を一行に押し込めたり独自タイプを既定値へ置き換えたりする処理は行いません。

色分けされたタイプ、スコープ、説明が見出しにまとまり、本文とフッターは別のブロックになる。

互換性の宣言を確認する

featは通常minorの意図を示しますが、!または有効な破壊的変更フッターがあればmajorの宣言になります。画面はその違いを表示します。コードの互換性や次に公開するバージョンを判定する機能ではなく、書かれた宣言を確認するための表示です。

互換性のある変更と、琥珀色の破壊的変更マーカーを持つ変更が異なる版の進み方を示す。

見落としやすい区切りを確認

01

候補にないタイプも入力する

コミットタイプの候補は入力の補助です。独自の名詞を直接入力できます。タイプとスコープは元の大小文字を保ちます。変更が機能追加なのか修正なのかは、実際の差分を見て利用者が選んでください。

02

フッターの続き方を知る

Refs: #42やCloses #42のような行から始めます。次の普通の行は直前の値の続きとなり、別の有効なトークンが現れると次の項目になります。本文の段落と同じつもりで書くと意味が変わるため、区切りを確認してください。

03

手動処理と古い結果を見分ける

自動処理は入力が止まってから350ミリ秒後に実行します。オフにすると操作ボタンとCtrl/Cmd + Enterを使えます。入力や!を変更した直後はコピーとダウンロードが無効になり、新しい結果が出るまで待機します。

タイプと段落を明確に分ける

日本語の説明と独自タイプ

説明、本文、フッターの値は日本語でも書けます。タイプを一覧に限定せず、FEATとfeatは同じ意図として解釈します。先頭行の文字数を表示しますが、50文字や72文字を超えたことだけでエラーにはしません。

完成済みテキストの構造検証

検証モードは見出し、空行、認識可能なフッターを調べます。エラーは行と列を示し、編集欄でも該当行を強調します。通常の文章中のコロンやURLは、それだけで不正なフッターにはなりません。

二通りの破壊的変更表示

!はタイプまたはスコープの後、コロンの直前に置きます。!があれば追加のフッターは必須ではありません。BREAKING CHANGE:とBREAKING-CHANGE:も使えます。この特別なトークンは大文字で、説明を伴う必要があります。

判定の対象と制約

リポジトリ独自の規則は対象外
構造が有効でもcommitlintやフックを通過する保証はありません。設定ファイル、タイプ一覧、命令形、小文字の強制は扱いません。説明だけから実際のコードがバグ修正かどうかを判断することもできません。
一度に一件、入力上限あり
最大20,000 UTF-16単位までで、組み立て後の記号と空行も上限に含みます。超過時は切り捨てずに拒否します。CRLFとCRはLFに統一し、作成時は本文とフッターの端の改行だけを除きます。内部の段落や空白は残ります。
文章とフッターの境界
検証では空行の直後にある有効なトークンがフッター開始候補になります。そのためNote: textはフッターとして読めますが、コロンを含む任意の文は本文に残ります。専用フッター欄では最初の行に正しいトークンと値が必要です。
Git操作や公開処理は行わない
コミットの実行、履歴編集、diffの読込、シェルコマンド、AIによる要約、履歴保存、共有URLは用意しません。majorなどは宣言の意味だけです。実際の版番号やrevertによる相殺、変更履歴の生成は対象外です。
例とクリアは確認して適用
内容がある場合は置換内容とUTF-16単位数をプレビューします。適用後は一度だけ取り消せ、入力、!と結果を同時に戻します。対象は現在のモードだけで、検証した文章を自動でフォームへ反映したり修正したりしません。

コミットメッセージ生成のよくある質問

カスタムタイプを追加できますか?

追加できます。タイプは自由入力で、候補は一般的な名前を示すだけです。空白や構造用の区切り文字を含まない形で入力してください。独自タイプに!がない場合、暗黙のSemVer上の影響は付与しません。

日本語でコミットメッセージを書いても良いですか?

書けます。要約、本文、フッターの値は日本語を受け付けます。読み手やチームの方針に合わせて言語を選んでください。ただしBREAKING CHANGEなどの規格上のトークンを日本語に置き換えることはできません。

コミットタイトル (1行目) の型は大文字か小文字のどちらがよいですか?

規格では大小文字のどちらも認めています。ツールは入力した表記を維持し、タイプの解釈は大小文字を区別しません。破壊的変更を示すBREAKING CHANGEとBREAKING-CHANGEは例外で、大文字が必要です。

これはSemVerとどのような関係を持っていますか?

fixはpatch、featはminor、!または有効な破壊的変更フッターはmajorの意図を示します。ここでは優先順位を含めた宣言だけを表示します。現在のバージョンやリリース方針を読み込まず、新しい版番号は計算しません。

Conventional Commitsは `revert` コミットをどのように扱いますか?

規格はrevertの具体的な処理を各ツールに委ねています。revertタイプとRefsフッターで対象を説明できますが、この検証は以前のコミットを取り消す計算や、取り消し後の公開バージョンの判断までは行いません。

確認したい書式がありますか?

コミット前に内容を確認

コミットメッセージ生成に戻り、文章の構造と宣言が実際の変更に合っているか確かめてから、最新の結果を出力してください。