Gitのコミットメッセージの基本ルール
Gitでの開発では、コミットメッセージが履歴の質を大きく左右します。
適切なメッセージを残しておくことで、変更内容の把握や原因調査がしやすくなり、長期的な保守性も高まります。
この記事では、Git初心者でも実践できるコミットメッセージの基本ルールを、理由とともに丁寧に解説します。
Contents
Gitのコミットメッセージとは何か
コミットメッセージとは、そのコミットで何を変更したのかを説明する短い文章です。
Gitは変更内容そのもの（差分）を記録しますが、「なぜその変更をしたのか」「何を目的とした変更なのか」は、コミットメッセージが担います。
Gitの仕組みやコミットそのものの役割については、以下の記事で詳しく解説しています。
なぜコミットメッセージが重要なのか
コミットメッセージが重要とされる理由は、主に次の3点です。
- 履歴を後から読み返せる
- 変更の意図を第三者が理解できる
- 不具合調査や差分確認が容易になる
Gitの履歴は、将来の自分だけでなく、他の開発者や数か月後のメンテナンス作業でも参照されます。
そのため、主観的・曖昧な表現ではなく、客観的で簡潔な記述が求められます。
コミットメッセージの基本構成
1行目は「要約」を書く
コミットメッセージの1行目には、変更内容の要点を簡潔に書きます。
- 何をしたのかが一目で分かる
- 50文字前後を目安にする
- 完了形ではなく「〜を追加」「〜を修正」などの形で書く
例
ヘッダーのナビゲーションを修正Gitのログ表示では1行目のみが一覧に表示されることが多いため、特に重要な部分です。
2行目は空行にする
1行目と本文（詳細説明）の間には、必ず1行空行を入れます。
ヘッダーのナビゲーションを修正
スマートフォン表示時にリンクが重なっていたため、
CSSを調整して表示を改善した。この形式はGit公式ドキュメントでも推奨されており、可読性が大きく向上します。
3行目以降に「詳細」を書く（必要な場合）
すべてのコミットで詳細を書く必要はありませんが、次のような場合は説明を補足すると有効です。
- なぜその変更が必要だったのか
- どのような方針で修正したのか
- 影響範囲や注意点
「何をしたか」よりも「なぜしたか」を補足する意識が重要です。
よく使われる書き方のルール
動詞から書き始める
コミットメッセージは、変更内容を端的に示す動詞から始めると分かりやすくなります。
例
- 追加
- 修正
- 削除
- 更新
- 変更
投稿一覧ページにページネーションを追加1コミット＝1つの変更内容にする
複数の目的を1つのコミットにまとめると、履歴の意味が分かりにくくなります。
- 機能追加
- バグ修正
- デザイン調整
これらは可能な限り分けてコミットするのが基本です。
コミットを細かく分ける考え方については、以下の記事も参考になります。
主観的・曖昧な表現を避ける
次のような表現は、後から見たときに内容が伝わりません。
- とりあえず修正
- ちょっと変更
- 微調整
代わりに、具体的な変更点が分かる表現を使います。
悪い例
デザインを修正良い例
トップページの余白を調整よくあるNGなコミットメッセージ例
修正test一旦対応これらは、変更内容や意図が一切分からず、履歴としての価値がほとんどありません。
チーム開発で特に意識したいポイント
チームでGitを使う場合、コミットメッセージは共有ドキュメントの一部になります。
- 誰が見ても理解できる表現にする
- 前提知識を必要としない書き方にする
- 一貫したルールを守る
ブランチ運用と合わせて考えることで、より分かりやすい履歴になります。
まとめ
Gitのコミットメッセージは、単なるメモではなく、開発履歴を支える重要な情報です。
- 1行目で変更内容を要約する
- 必要に応じて詳細を書く
- 客観的で具体的な表現を使う
- 1コミット1目的を意識する
これらの基本ルールを押さえることで、読みやすく、信頼できるGit履歴を残せるようになります。