良いコミットメッセージの書き方

「修正」が 3 つ並んで、どれか分からない

本番でバグが出て、原因の行を特定したとします。次にやるのは、その行をいつ誰がなぜ変えたのかを調べることです。

$ git log --oneline src/price.js
7e5c3d9 修正
4d9b7e1 対応
8f3c1a2 fix

これでは 3 件とも開いて差分を読むしかありません。しかも読んでも、なぜそうしたのかは分かりません。

$ git log --oneline src/price.js
7e5c3d9 消費税の端数処理を切り捨てから四捨五入に変更
4d9b7e1 送料無料の判定を税抜金額で行うよう修正
8f3c1a2 商品価格の計算ロジックを追加

差分を開く前に、探しているものがどれか見当が付きます。差はメッセージの書き方だけです。メッセージは、あとから探す人が差分を開かずに判断するために書きます。その人は、たいてい半年後の自分です。

差分を見れば分かることは書かない

1 行目に守るルールは 3 つで足ります。50 字以内に収めること、句点を付けないこと、1 文で言い切ることです。

50 字という上限には理由があります。git log --oneline は 1 行に名前と件名を並べるので、長いと切れます。GitHub の一覧も 70 文字あたりで省略されます。切られた先に大事な情報を置くと、誰にも読まれません。日本語なら 50 字はかなり書けるので、収まらないなら、たいてい 1 つのコミットに 2 つの話が入っています。

そのうえで、書く中身を選びます。

判定は簡単です。書いた 1 行を読んで、どのあたりを触ったコミットか見当が付き、かつファイル名そのものは書かれていないなら合格です。

文体は「〜する」でも体言止めでもよく、日本語で構いません。ただしチームの中で混ぜないでください。参加するリポジトリの git log を先に読んで、そこの流儀に合わせます。

「なぜ」は本文にしか残せない

1 行目で「何をしたか」は伝わります。差分を読んでも絶対に分からないのは「なぜ」のほうです。それを書く場所が本文です。

消費税の端数処理を四捨五入に変更

請求書の合計が会計システムと 1 円ずれる問い合わせが 3 件あった。
原因は端数を切り捨てていたことで、取引先の会計システムは四捨五入していた。
先方のシステムは変更できないため、こちらを合わせる方針とした。

2026-08-01 以前に発行済みの請求書には影響しない。

問い合わせが何件あったか、採用しなかった案は何か、既存のデータに影響があるか。どれも差分からは読み取れません。半年後に「なぜ四捨五入にしたのか」と疑問を持った人は、この本文で納得できます。

1 行目と本文の間には、必ず空行を入れてください。Git は空行までを件名として扱うので、詰めて書くと git log --oneline の表示が崩れます。git commit -m "件名" -m "本文" と -m を 2 回書けば、Git が間に空行を入れてくれます。

本文は必須ではありません。半年後の自分が 1 行目だけ読んで納得できるなら、それで足ります。

解説

打とうとして「修正」としか書けないときは、文才の問題ではありません。1 つのコミットに複数の話が混ざっていて、1 文で説明できなくなっている合図です。まず変更を分けてください。

書いたあとで打ち間違いに気づいたら、まだ送っていない直前の 1 件なら git commit --amend で言い直せます。送ってしまったものは、少し恥ずかしくてもそのまま残すほうが安全です。