Git コミットメッセージの書き方｜文字数の目安とベストプラクティス
Git のコミットメッセージは、コードの変更履歴を読み解くための重要な手がかりです。適切に書かれたメッセージは、数か月後のコードレビューやバグ調査を大幅に効率化します。一方で、曖昧なメッセージは技術的負債となり、チーム全体の生産性を低下させます。この記事では、コミットメッセージの文字数の目安と、実務で役立つベストプラクティスを解説します。Git の運用を体系的に学びたい方は、Git 実践入門の書籍も参考になります。メッセージの文字数確認には 文字数カウントス をご活用ください。
コミットメッセージにまつわる意外な事実
「件名 50 文字、本文 72 文字折り返し」という慣例の起源は、電子メールの時代に遡ります。Git の開発者 Linus Torvalds は、Linux カーネルの開発でパッチをメールで送受信していた慣習を Git に引き継ぎました。メールクライアントの標準的な表示幅が 80 桁であり、引用符やインデントを考慮すると本文は 72 文字が最適だったのです。
GitHub のデータによると、オープンソースプロジェクトのコミットメッセージの平均文字数は推定 40〜50 文字程度です。しかし、メッセージの品質とプロジェクトの健全性には相関があるとされており、メッセージが短すぎる (10 文字未満) プロジェクトはバグ修正の効率が低い傾向にあるという分析もあります。
主要 OSS プロジェクトのコミットメッセージを分析すると、件名の文字数には明確な傾向が見られます。Linux カーネルでは件名の中央値が約 55 文字で、50 文字ルールをやや超過するコミットが多い一方、Conventional Commits を採用している Angular や Vue.js では中央値が 45 文字前後に収まっています。プレフィックス (feat: や fix:) が 5〜10 文字を消費するため、実質的な説明部分は 35〜40 文字に制限される点が、結果的に簡潔なメッセージを促しています。
50/72 ルールの由来と技術的背景
50/72 ルールの根拠は、ターミナルの表示幅 80 カラムに由来します。git log のデフォルト出力では、コミットハッシュ (7 文字) とスペースが先頭に付くため、件名に使える実質的な幅は約 72 文字です。さらに git log --oneline では、ハッシュ + スペースで 8 文字を消費するため、残り 72 文字が件名の表示領域になります。50 文字という推奨値は、この 72 文字のハードリミットに対して余裕を持たせた「ソフトリミット」として機能しています。
本文の 72 文字折り返しにも明確な理由があります。git format-patch で生成されるパッチメールでは、メーリングリストでの引用時に > (2 文字) が先頭に追加されます。2 段階の引用 (> > ) で 4 文字、さらにインデント 4 文字を加えると、80 カラムの表示幅に収まるのは 72 文字が限界です。この計算が、現在も広く使われている 72 文字ルールの根拠です。
コミットメッセージの基本構造と文字数の目安
Git コミットメッセージは「件名 (subject)」と「本文 (body)」の 2 部構成が標準です。件名と本文の間には空行を 1 行挟みます。この構造は git log --oneline や GitHub のコミット一覧で件名だけが表示される仕組みに対応しています。
| 要素 | 文字数の目安 | 理由 |
|---|---|---|
| 件名 (subject) | 50 文字以内 (英語) | GitHub の一覧表示で途切れずに表示される長さ |
| 件名 (ハードリミット) | 72 文字以内 | 72 文字を超えると GitHub 上で省略記号 (...) が付く |
| 本文の 1 行あたり | 72 文字で折り返し | ターミナルの標準幅 (80 桁) でインデント分を考慮した値 |
| 本文全体 | 制限なし | 必要に応じて詳細な説明を記述可能 |
GitHub と GitLab では件名の表示切れポイントが異なります。GitHub のコミット一覧では約 72 文字で省略記号が付きますが、リポジトリのトップページでは約 50 文字で切れます。GitLab のコミット一覧では約 80 文字まで表示されるため、GitHub よりやや余裕があります。ただし、両プラットフォームで一貫した表示を確保するには、50 文字以内に収めるのが最も安全です。
全角と半角の文字数の違いにも注意が必要です。日本語を含むコミットメッセージの場合、件名は 25 文字程度を目安にすると GitHub 上で見切れにくくなります。
日本語コミットメッセージの文字数問題
日本語でコミットメッセージを書く場合、文字数とバイト数の違いが深刻な問題を引き起こします。Git 内部では文字列を UTF-8 で扱うため、全角文字 1 文字は 3 バイトを消費します。GitHub の件名表示切れはバイト数ではなく表示幅 (カラム数) で判定されるため、全角文字は 2 カラム分を占有します。つまり、50 カラムの表示幅に収まる日本語は最大 25 文字です。
git log をターミナルで表示する際にも、マルチバイト文字の幅計算が問題になります。多くのターミナルエミュレータは East Asian Width プロパティに基づいて全角文字を 2 カラム幅で表示しますが、一部の環境 (特に古い Windows のコマンドプロンプト) では幅計算が正しく行われず、表示が崩れることがあります。git log --oneline の出力でカラムが揃わない場合は、ターミナルの文字幅設定を確認してください。
チームで日本語コミットメッセージを採用する場合は、「プレフィックスは英語、説明は日本語」というハイブリッド方式が実用的です。fix(auth): ログイン時のセッション復元を修正 のように書けば、git log --oneline --grep="^fix" による型別フィルタリングが機能しつつ、日本語話者にとって読みやすいメッセージになります。
Conventional Commits とプレフィックスの使い方
Conventional Commits は、コミットメッセージに統一的な構造を持たせる規約です。メッセージの先頭にプレフィックス (型) を付けることで、変更の種類が一目で判別でき、CHANGELOG の自動生成やセマンティックバージョニングとの連携も可能になります。
この規約の設計思想は、セマンティックバージョニング (SemVer) との自動連携にあります。feat は MINOR バージョンの更新、fix は PATCH バージョンの更新に対応し、BREAKING CHANGE フッターを含むコミットは MAJOR バージョンの更新を示します。この対応関係により、semantic-release や standard-version などのツールがコミット履歴からバージョン番号を自動決定できます。
基本フォーマットは <type>(<scope>): <description> です。scope は省略可能で、変更対象のモジュールやコンポーネントを示します。
| プレフィックス | 用途 | 例 |
|---|---|---|
feat |
新機能の追加 | feat(auth): add OAuth2 login support |
fix |
バグ修正 | fix(api): resolve null pointer in user endpoint |
docs |
ドキュメントの変更 | docs: update API reference for v2 |
style |
コードスタイルの変更 (動作に影響なし) | style: fix indentation in config file |
refactor |
リファクタリング | refactor(db): simplify query builder logic |
test |
テストの追加・修正 | test: add unit tests for payment module |
chore |
ビルドやツールの変更 | chore: upgrade webpack to v5 |
perf |
パフォーマンス改善 | perf(search): add index for full-text query |
ci |
CI/CD 設定の変更 | ci: add GitHub Actions workflow |
プレフィックスを使うことで、git log --oneline の出力を眺めるだけで変更の全体像を把握できます。チーム開発では、プレフィックスの種類と使い分けをドキュメント化しておくと運用がスムーズです。
なぜ命令形 (imperative mood) が推奨されるのか
英語のコミットメッセージで命令形が推奨される理由は、Git 自体の設計に根ざしています。Git が自動生成するメッセージ — Merge branch 'feature'、Revert "Add login form"、Cherry-pick from abc1234 — はすべて命令形です。ユーザーが書くメッセージもこれに合わせることで、git log の出力全体が統一された文体になります。
命令形のメッセージは「このコミットを適用すると何が起きるか」を説明する文として読めます。Add user authentication は「ユーザー認証を追加する」という意味であり、コミットの効果を端的に表現しています。一方、Added user authentication (過去形) は「ユーザー認証を追加した」という報告であり、コミットの効果ではなく作業の記録になってしまいます。
判断に迷ったときは、「If applied, this commit will ___」の空欄にメッセージを入れて自然に読めるかを確認してください。If applied, this commit will add user authentication は自然ですが、If applied, this commit will added user authentication は文法的に不自然です。
良いコミットメッセージと悪いコミットメッセージの比較
コミットメッセージの品質は、プロジェクトの保守性に直結します。以下に、実務でよく見かける悪い例と、改善した良い例を対比して示します。
| 悪い例 | 問題点 | 良い例 |
|---|---|---|
fix bug |
何のバグか不明 | fix(cart): prevent duplicate items on rapid click |
update |
何を更新したか不明 | docs: add setup instructions for local dev |
WIP |
作業途中のコミットが履歴に残る | feat(ui): add skeleton loader for product list |
asdfgh |
意味のない文字列 | refactor: extract validation logic into helper |
Fixed the thing that was broken in the last commit because it was not working properly |
冗長で 50 文字を大幅に超過 | fix(auth): restore session after token refresh |
- 件名は命令形で書く: 「Added」ではなく「Add」、「Fixed」ではなく「Fix」を使う。Git 自体が生成するメッセージ (Merge branch...) と文体が統一される
- 件名の末尾にピリオドを付けない: スペースの節約と慣例の両面から推奨される
- 「なぜ」を本文に書く: 件名は「何をしたか」、本文は「なぜその変更が必要だったか」を記述する
- 1 コミット = 1 論理的変更: 複数の無関係な変更を 1 つのコミットにまとめない
squash merge と revert のメッセージ設計
squash merge を使用する場合、複数のコミットが 1 つに統合されるため、メッセージの設計が通常のコミットとは異なります。GitHub の squash merge では、デフォルトでプルリクエストのタイトルが件名に、個別のコミットメッセージが本文に箇条書きで挿入されます。この自動生成メッセージをそのまま使うと、本文が冗長になりがちです。squash merge 時は、プルリクエストの説明文を本文として使い、変更の目的と影響範囲を簡潔にまとめるのが効果的です。
revert コミットのメッセージには、Git が自動生成する Revert "<original subject>" の形式をそのまま使うのが慣例です。本文には、元のコミットハッシュ (This reverts commit <hash>.) に加えて、revert の理由を必ず記述してください。理由がないと、後から履歴を追う際に「なぜ取り消したのか」が分からなくなります。複数のコミットを一括で revert する場合は、revert: undo feature X (commits abc..def) のように範囲を明示すると、履歴の追跡が容易になります。
チーム開発でのコミットメッセージ運用ルール
個人開発ではメッセージの書き方に自由度がありますが、チーム開発では統一されたルールが不可欠です。以下の施策を導入すると、メッセージの品質を組織的に維持できます。チーム開発の効率化については、チーム開発ワークフローの技術書で詳しく解説されています。
- commitlint の導入: Conventional Commits の規約に沿っているかを自動チェックするツール。CI に組み込めば、規約違反のコミットをマージ前に検出できる
- Git hooks (husky) の活用:
commit-msgフックでローカル環境でもメッセージのフォーマットを検証する - テンプレートの設定:
git config commit.templateでチーム共通のテンプレートを設定し、記述漏れを防ぐ - コードレビューでメッセージも確認する: プルリクエストのレビュー時に、コミットメッセージの品質もチェック対象に含める
commitlint と husky を組み合わせた設定例を示します。npm install --save-dev @commitlint/cli @commitlint/config-conventional husky でインストールした後、プロジェクトルートに commitlint.config.js を作成し、module.exports = { extends: ['@commitlint/config-conventional'] }; と記述します。次に npx husky init で husky を初期化し、.husky/commit-msg ファイルに npx --no -- commitlint --edit $1 を記述すれば、コミット時に自動でメッセージの検証が走ります。
命名規則と文字数の目安と同様に、コミットメッセージのルールもチームの規模や文化に合わせて段階的に導入するのが現実的です。まずはプレフィックスの統一から始め、慣れてきたら commitlint を導入するといった段階的なアプローチが効果的です。
AI によるコミットメッセージ生成の活用と注意点
GitHub Copilot や各種エディタ拡張が提供するコミットメッセージの自動生成機能は、メッセージ作成の手間を大幅に削減します。差分 (diff) を解析して変更内容を要約するため、「何を変更したか」の記述精度は高い傾向にあります。
ただし、自動生成には限界があります。最大の弱点は「なぜその変更が必要だったか」を推測できない点です。コードの差分からは変更の動機やビジネス上の背景を読み取れないため、本文に記述すべき「Why」の部分は人間が補完する必要があります。また、自動生成されたメッセージは冗長になりがちで、50 文字の件名制限を超過することも少なくありません。生成結果をそのまま使うのではなく、必ず人間がレビューし、不要な情報を削って簡潔にまとめる習慣が重要です。
まとめ
Git コミットメッセージは、件名 50 文字以内・本文 72 文字折り返しが広く受け入れられている慣例です。この数値はターミナル幅 80 カラムとメール引用の慣習に由来しており、GitHub・GitLab の表示仕様とも整合しています。Conventional Commits のプレフィックスを活用すれば、変更の種類が一目で分かり、CHANGELOG の自動生成にも対応できます。日本語でメッセージを書く場合は全角文字の表示幅に注意し、件名は 25 文字程度を目安にしてください。良いメッセージは「何を」「なぜ」変更したかを簡潔に伝え、悪いメッセージは曖昧で情報量が不足しています。コミットメッセージの文字数を確認する際は、文字数カウントス をぜひご活用ください。