Git コミットメッセージテンプレート

ターミナルとエディタで展開される、再利用可能な Conventional Commits 形式の PR 対応メッセージテンプレート。

テンプレート カテゴリの概要

一貫したコミットメッセージはリポジトリの履歴を読みやすくし、自動 changelog を可能にし、コードレビューを速くします — しかし、適切に構造化された Conventional Commit を毎回手で打つのは十分に面倒で、ほとんどの開発者は1行のサマリーに戻ってしまいます。テキストエキスパンダーは、短いトリガーをタイプ、scope、サマリー、ボディ、フッターがすでに配置された完全なコミットの足場に変えることでこれを解決し、形式を覚える代わりに詳細を埋めるだけにします。Lightning Assist はシステム全体で機能するので — ほとんどのコミットが実際に行われるターミナルや VS Code のコミットボックスを含む — コマンドライン、IDE、Git GUI のどこからコミットしても同じテンプレートが機能します。Push-to-Talk 音声は、デバッグの最中で手がキーボードから離れているときに長めのボディ段落を口述することさえできます。

これらのテンプレートを使用する場合

すべてのコミットでコミットメッセージテンプレートを使いますが、後で重要になるコミットで最も効果を発揮します。再訪するバグ修正、他チームに影響する breaking changes、履歴からリリースや changelog を自動生成するリポジトリのコミットなどです。プロジェクトが Conventional Commits、semantic-release、あるいは何らかの changelog 自動化を使っているなら、一貫した足場は単なる整頓ではなく — それこそが tooling を機能させるものです。個人プロジェクトでも、一貫した形式で書かれた読みやすい git log は、リグレッションを bisect するときや、なぜ6か月前に変更が行われたかを思い出そうとするときに実際の時間を節約します。

このカテゴリのテンプレート例

  • Conventional Commit の足場: タイプ、任意の scope、サマリー、ボディ、ticket 参照付きフッター。
  • バグ文脈付きの fix コミット: 何が壊れたか、修正、そしてそれが閉じる issue。
  • Breaking-change コミット: 変更と、リリース tooling 向けに明確にマークされた BREAKING CHANGE フッター。

実際のテンプレート例

Conventional Commit の足場

自動バージョニングと changelog ツールを支える Conventional Commits 仕様に従った、あらゆるコミットの日常的なテンプレートです。構造は、タイプ（feat、fix、chore、docs、refactor、test など）、括弧内の任意の scope、約50文字未満の簡潔な命令形サマリー、空行、次に理由を説明するボディ、そして ticket 参照のフッターです。これを ;cc のような短いトリガーに保ち、メッセージを書く前にターミナルで展開されるようにします。毎回一貫した足場を埋めることこそが git log を数か月後に本当に役立つものにし、changelog を自動生成できるリリースツールとできないツールの違いになります。

[#type#]([#scope#]): [#summary#]

[#why this change was made#]

Refs: [#ticket#]

バグ文脈付きの fix コミット

バグ修正コミットは将来のあなたが最も理解する必要があるものなので、「fix bug」以上の価値があります。3つを捉えます。何が壊れたか（観察可能な症状）、修正が何をするか、そしてトラッカーが自動更新されるようにそれがどの issue を閉じるか。「Closes #」フッターこそがコミットを issue トラッカーに結びつけ、ほとんどのプラットフォームで merge 時に ticket を閉じます。これを ;fix のようなトリガーに保ちます。デバッグセッションの深みで根本原因を平易な言葉で記録したいとき、Push-to-Talk 音声はフローを壊さずにボディを口述させ、AI Enhance はとりとめのない口述説明をきれいな段落に引き締めます。

fix([#scope#]): [#what was broken#]

[#root cause and what the fix does#]

Closes #[#issue#]

Breaking-change コミット

コミットが API、設定形式、または他のコードが依存する契約を変更するとき、リリース tooling が major バージョンの引き上げをトリガーし changelog がユーザーに警告するよう、breaking change は明示的にマークされなければなりません。Conventional Commits 標準はまさにこのために BREAKING CHANGE: フッター（またはタイプ後の !）を使います。何が壊れたか、そして何より、利用者が移行のために何をしなければならないかを明記します — 移行ノートのない breaking change はサポート質問の洪水になるだけです。これを ;ccbreak のような意図的なトリガーに保ち、本当にそう意図するときだけ手を伸ばすようにします。breaking change を誤ってラベル付けすることはラベル付けしないより悪いからです。

[#type#]([#scope#])!: [#summary#]

[#what changed#]

BREAKING CHANGE: [#what consumers must change to migrate#]

Refs: [#ticket#]

始め方

タイプ、scope、サマリー、ボディ、ticket のプレースホルダーを備えた ;cc のような短いトリガーで一般的な Conventional Commit の足場から始めます。fix タイプと「Closes #」フッターを事前入力した ;fix バリエーション、そして稀だが重要な breaking コミット用に BREAKING CHANGE フッターを備えた ;ccbreak バリエーションを追加します。ターミナルやエディタのコミットボックスにトリガーを入力すると入力中にインラインで展開されます — ホットキーは不要で、展開はシステム全体なので両方で同じように機能します。足場が自然に感じられるようになったら、PR 説明とコードレビュー返信のテンプレートを追加し、変更提出フロー全体を一貫させます。

プロのヒント

  • サマリー行は ~50 文字未満かつ命令形で（「add」であって「added」ではない）— ほとんどの git tooling とレビュアーはこの慣習を期待します。
  • fix コミットに「Closes #[issue]」フッターを使い、変更の merge がトラッカーのリンクされた ticket を自動的に閉じるようにします。
  • breaking-change テンプレートは本当の契約変更のために取っておき、常に移行ステップを含めます — それのない破壊ノートはサポート負荷を生むだけです。
  • デバッグの最中で手がキーボードから離れているとき Push-to-Talk でコミットボディを口述し、その後 AI Enhance で表現を引き締めます。

あらゆるアプリでこれらのテンプレートを使用

これらの例から再利用可能なスニペットを作成し、クイック アクセス、トリガー ショートカット、または AI 拡張機能を使用して実行します。

無料トライアルを開始する

関連ページとスニペット

ワークフローに関連するガイド、テンプレート、比較を調べてください。