最終更新:

Git コミットメッセージの書き方｜文字数の目安とベストプラクティス

約 7 分で読めます

Git のコミットメッセージは、コードの変更履歴を読み解くための重要な手がかりです。適切に書かれたメッセージは、数か月後のコードレビューやバグ調査を大幅に効率化します。一方で、曖昧なメッセージは技術的負債となり、チーム全体の生産性を低下させます。この記事では、コミットメッセージの文字数の目安と、実務で役立つベストプラクティスを解説します。メッセージの文字数確認には 文字数カウントス をご活用ください。

文字数の目安はどこまで拘束力があるか

「件名 50 文字、本文 72 文字折り返し」という慣例の起源は、電子メールの時代に遡ります。Git の開発者 Linus Torvalds は、Linux カーネルの開発でパッチをメールで送受信していた慣習を Git に引き継ぎました。メールクライアントの標準的な表示幅が 80 桁だったため、引用符やインデントを差し引いた本文の幅として 72 文字が定着したのです。

ここで押さえておきたいのは、Git 自体がコミットメッセージの長さを制限していないことです。git commit のマニュアルは「必須ではないが、変更を要約した 50 文字以内の 1 行から始めるとよい」と述べるにとどまり、本文の折り返し幅については数値を示していません。つまり 50 も 72 も、ツールが弾く上限ではなく「一覧表示で切れずに読めるか」「引用しても崩れないか」を担保するための運用上の目安です。この違いを理解しておくと、プラットフォームや表示環境が変わったときに数値だけを機械的に守って本質を外す、という失敗を避けられます。

実務での落とし穴は、Conventional Commits を採用したときに件名の予算が目減りする点です。feat(auth): のようなプレフィックスと scope は、それ自体が件名の先頭を消費します。50 文字の枠は変わらないため、説明に割ける文字数はその分だけ減ります。scope を階層的に長く書く運用にすると説明が入りきらなくなるので、scope は 1 語で表せる粒度に保つのが実用的です。

50/72 ルールの由来と技術的背景

50/72 ルールの背景にあるのは、ターミナルの表示幅 80 カラムです。git log のデフォルト表示ではコミットハッシュが独立した行に出力され、件名と本文は 4 文字分インデントされて表示されます。git log --oneline では短縮ハッシュ (既定 7 文字) とスペースで 8 文字を消費するため、80 カラムの端末で件名に残る幅は 72 文字です。50 文字という推奨値は、この 72 文字に対して余裕を持たせた「ソフトリミット」として機能しています。

本文の 72 文字折り返しにも明確な理由があります。git format-patch で生成されるパッチメールでは、メーリングリストでの引用時に > (2 文字) が先頭に追加されます。2 段階の引用 (> > ) で 4 文字、さらに git log のインデント 4 文字を加えると、80 カラムの表示幅に収まるのは 72 文字が限界です。この見積もりが 72 文字ルールの説明として広く共有されています (前述のとおり Git のマニュアル自体は本文幅を規定していません)。

コミットメッセージの基本構造と文字数の目安

Git コミットメッセージは「件名 (subject)」と「本文 (body)」の 2 部構成が標準です。件名と本文の間には空行を 1 行挟みます。この構造は git log --oneline や GitHub のコミット一覧で件名だけが表示される仕組みに対応しています。

要素 文字数の目安 理由
件名 (subject) 50 文字以内 (英語) git commit のマニュアルが挙げる目安。ホスティングサービスの一覧表示でも途切れにくい
件名 (実用上の上限) 72 文字以内 80 カラムの端末で git log --oneline が折り返さずに収まる幅
本文の 1 行あたり 72 文字で折り返し ターミナルの標準幅 (80 桁) でインデント分を考慮した値
本文全体 制限なし 必要に応じて詳細な説明を記述可能

ホスティングサービスの画面では、長い件名は途中で省略されます。省略が始まる位置は同じサービス内でも画面によって異なり (コミット一覧とリポジトリのトップページで違う、など)、公式に文字数が公表されているわけでもありません。デザイン変更で位置が動くことも珍しくないため、特定の桁数を狙って調整するのは労力に見合いません。どの画面でも要点が読めるようにするには、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" のように、いずれも命令形で始まります。ユーザーが書くメッセージもこれに合わせることで、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

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 と 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 カラムとメール引用の慣習に由来する運用上の目安で、Git 自体がメッセージの長さを制限しているわけではありません。Conventional Commits のプレフィックスを活用すれば、変更の種類が一目で分かり、CHANGELOG の自動生成にも対応できます。日本語でメッセージを書く場合は全角文字の表示幅に注意し、件名は 25 文字程度を目安にしてください。良いメッセージは「何を」「なぜ」変更したかを簡潔に伝え、悪いメッセージは曖昧で情報量が不足しています。コミットメッセージの文字数を確認する際は、文字数カウントス をぜひご活用ください。

この記事を共有