← ブログ · 2026年4月9日 · ConvertCaseHQ チーム · 10 分で読めます

Git コミットメッセージの書き方：件名、大文字・小文字、Conventional Commits の決まり

英語で書くなら、きれいな Git のコミットメッセージは、短い件名の行（目安は 50 文字）を命令形（"Added" ではなく "Add"）で書き、ピリオドを付けません。続いて空行を 1 つ挟み、変更した理由を説明する本文を 72 文字で折り返して書きます。大文字・小文字については、1 つの規則を選んで守り通しましょう。feat: や docs: のようなプレフィックスがあるなら、その後ろの単語は小文字にするのが一般的です。プレフィックスがなければ、昔ながらの助言は最初の単語を大文字にすることです。

これらのルールは Git 自体では強制されません。履歴がばらばらになっていくのはそのためです。以下では、ルールの内容、それぞれの出どころ、そして覚えておかなくても済むようにツールでチェックさせる方法を紹介します。

よいコミットメッセージの構成

fix(editor): keep cursor position after paste

Pasting into an empty textarea moved the cursor to the start, because
the change handler replaced the value before restoring the selection.
Restore the selection after updating the value instead.

Fixes #142

構成は 3 つの部分です。コミットが何をするのかを述べる件名、その理由を述べる本文、そして参照やメタデータのための任意のフッターです。Git 自身のドキュメントは、メッセージの先頭を「a single short (no more than 50 characters) line summarizing the change, followed by a blank line and then a more thorough description」（変更を要約した短い 1 行（50 文字以内）、続いて空行、それからより詳しい説明）で始めることを勧めています。最初の空行までがコミットのタイトルとして扱われ、git log --oneline、git shortlog、git format-patch が表示するのもこの部分です。

件名：短く、命令形で、ピリオドなし

50 文字はソフトリミット、つまり厳密な上限ではなく目安です。Git プロジェクト自身の SubmittingPatches ガイドもまさにそう呼んでいて、貢献者に「skip the full stop」（ピリオドを付けない）ことを求めています。50 文字以内に収まらないなら、そのコミットが 2 つのことをしているサインであることがよくあります。

同じガイドは、コードベースに命令を出すように「describe your changes in imperative mood」（変更内容を命令形で書く）ことも求めています。「make xyzzy do frotz」であって、「makes xyzzy do frotz」や「changed xyzzy to do frotz」ではありません。Chris Beams の「コミットメッセージの 7 つのルール」には、便利なテストがあります。よい件名は、「If applied, this commit will …」（このコミットを適用すると、…）という文を完成させます。

• 「If applied, this commit will add CSV export」は成り立ちます。
• 「If applied, this commit will added CSV export」は成り立ちません。
• 「If applied, this commit will bug fixes」も成り立たず、読み手に何も伝えません。

命令形は、Git が自動で書いてくれるメッセージ（Merge branch 'main' や Revert "…" など）とも一致するので、自分のコミットもログの中で同じ調子で読めます。

件名の大文字・小文字：2 つの流派

ここは助言が本当に食い違うところで、正解は、件名がプレフィックスで始まるかどうかによって変わります。

Git プロジェクトのやり方には、まねしたい細かな点があります。プレフィックスの後で大文字を外すのは最初の単語だけで、それも最初の単語だからという理由によります。常に大文字で書く単語は、そのまま大文字です。Git プロジェクト自身の例は refs: HEAD is also treated as a ref で、HEAD は常に大文字で書くからです。同じ考え方で、fix: handle iOS paste や docs: update README badges になります。

私たちの考えはこうです。プレフィックスがあるなら、名前や略語でない限り最初の単語を小文字にします。ないなら大文字にします。本当の間違いは、2 つのスタイルを混ぜることだけです。git log --oneline を使うと件名が一覧になり、数行ごとに大文字・小文字が切り替わる一覧は、雑に見えるからです。同じ考え方をドキュメントに当てはめた話は、ドキュメントの表記ゆれをなくす方法のガイドをご覧ください。

Conventional Commits 仕様が実際に定めていること

Conventional Commits 1.0.0 仕様は、次の構造を定義しています。

<type>[optional scope]: <description>

[optional body]

[optional footer(s)]

主なルールを簡単にまとめます。

• feat（新機能）と fix（バグ修正）は仕様が定義している 2 つの種別で、Semantic Versioning の MINOR リリースと PATCH リリースに対応し、破壊的変更は MAJOR に対応します。ほかの種別も使えます。仕様が挙げているのは build、chore、ci、docs、style、refactor、perf、test で、これらは、Angular の規約を土台にした commitlint の conventional 設定が推奨するものです。
• 破壊的変更は、コロンの前の !（feat!: drop Node 16 support）か、BREAKING CHANGE: フッターで示します。このフッターは大文字でなければなりません。
• この形式を読み取るツールは、BREAKING CHANGE を除き、大文字・小文字を区別するものとして扱ってはいけません。種別を小文字にするか大文字にするかについて、仕様の FAQ は、どちらの書き方でもよいが「but it's best to be consistent」（統一するのが最善）と述べています。

仕様は、件名の長さを定めておらず、命令形も求めていません。それらは Git の慣習から来ています。

commitlint が仕様より厳しい点

commitlint の @commitlint/config-conventional はこの形式を強制する定番の方法で、デフォルトの設定は仕様より踏み込んでいます。バージョン 21 で、サンプルの件名を試しました。

注意したいのは README の行です。fix: README typo や feat: URLSearchParams support のように、略語やクラス名で始まる件名は、Git プロジェクトなら同等の書き方を受け入れるのに、拒否されます。略語が先頭に来ないよう言い換えるか、設定で subject-case ルールを緩めてください。ヘッダーの長さの既定の上限は 100 文字なので、commitlint が 50 文字を守らせることもありません。

本文：72 文字で折り返し、理由を説明する

Git はメッセージを自動で折り返しません。Tim Pope の 2008 年の説明は今も通用します。git log はメッセージを 4 文字分インデントするので、80 桁の端末では、右側にも対称になるよう 4 文字分あけると 72 桁が残ります。また、git format-patch でコミットをメールで送るときも、折り返したテキストなら読みやすさを保てます。エディターに折り返し機能がなければ、当サイトの「N 文字でテキストを折り返す」ツールで、段落を単語の区切りで 72 文字に折り返せます。

本文は、diff では伝わらないことのために使います。問題点、この修正にした理由、試してうまくいかなかったことです。コマンドラインからは、-m ごとに独立した段落になるので、git commit -m "fix: keep cursor after paste" -m "Pasting into…" で、件名、空行、本文ができあがります。

チェックはツールに任せる

• VS Code："git.inputValidation": true を設定します。すると、コミットボックスで件名が 50 文字を超えたとき（git.inputValidationSubjectLength）や、ほかの行が 72 文字を超えたとき（git.inputValidationLength）に警告が出ます。
• Vim：コミットメッセージ用の同梱の設定は、本文を 72 文字で折り返し（textwidth=72）、件名のハイライトを 50 文字で止めます。
• コミットテンプレート：git config commit.template ~/.gitmessage を設定すると、コミットのたびに、リマインダーが書かれた状態でエディターが開きます。
• commit-msg フック：依存関係なしでチェックできます。次の内容を .git/hooks/commit-msg として保存し、実行可能にしてください。

#!/bin/sh
# Checks the subject line of every commit message.
subject=$(head -n 1 "$1")
length=${#subject}   # counts bytes in some shells; fine for ASCII subjects

if [ "$length" -gt 72 ]; then
  echo "commit-msg: subject is $length characters (limit 72, aim for 50)" >&2
  exit 1
fi
if [ "$length" -gt 50 ]; then
  echo "commit-msg: note, subject is $length characters (aim for 50)" >&2
fi
case "$subject" in
  *.) echo "commit-msg: drop the full stop at the end of the subject" >&2
      exit 1 ;;
esac
if [ -n "$(sed -n 2p "$1")" ]; then
  echo "commit-msg: leave line 2 blank, between subject and body" >&2
  exit 1
fi

このフックは、50 文字を超えると警告を出し、72 文字を超える件名、末尾のピリオド、空行の欠落は拒否します。どうしても必要なときは git commit --no-verify でスキップできます。コミットの前にさっと文字数を確かめるには、件名を当サイトの文字カウンターに貼り付けてください。

チェックリストをまとめます。命令形で 50 文字程度、ピリオドなしの件名。リポジトリ全体で 1 つだけの大文字・小文字のルール。空行。理由を説明する、72 文字で折り返した本文。そして、忙しい週でもルールが守られるようにするフックかリンターです。