blog 開発

【チーム開発】Gitのコミットメッセージの書き方

こんにちは、鈴木です。
今回は、Gitのコミットメッセージの書き方について勉強していこうと思います!

想定読者

  • チーム開発を初めて行うエンジニア
  • 未経験エンジニア

コミットメッセージとは

コミットログのコードの変更履歴に「どのように変更したか」という情報は基本的に含まれます。ところが、コードをなんで変更したのかというのは、コミットメッセージを読まないとわかりません。もちろん変更した本人に直接聞けば意図はわかりますが、常に聞ける状態であるとは限りません。

なので、「なんでコードを変更したのか」という情報を共有するために、コミットメッセージが存在すると思ってください。
さらにコミットメッセージは、未来の自分を含めた他人が読むものです。なので、以前紹介した要件定義と同じで誰がみてもわかるように記載する思いやりが必要です。

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

フォーマット

1行目:変更内容の要約(タイトルか概要)
2行目:(空白)
3行目:変更した理由(詳細)

すずき

日本語でも英語でもOK リポジトリ内で統一しよう!

コミットメッセージの良い例と悪い例

良い例

  • なぜそのコードを変更したのかが記載されている。
  • パット見で理解しやすい工夫がされている。
  • 必要なコード以外の情報も取得できる。

悪い例

  • なぜコードを変更したのかが記載されていない。
  • 抽象的すぎる
すずき

悪い例を解説していくよ!

例えば、コミットメッセージ:「指摘事項を反映した」だけだと、変えた意図も分からなければ、何の指摘事項かも分からないなんて悲惨な状態になります。なので、指摘事項を反映したではなく、「無限ループが発生する余地があったため変更した」などの具体的なワードを使うのが正しいコミットメッセージになります。

良いコミットメッセージを書くメリット

  • コードを読むだけでは分からない背景がわかる
  • コードレビューの負担が減る
  • 書き手がコードを書いた意図を話せなくても大丈夫

このような利点があるので、皆さんもコミットメッセージに命かけて読みやすいメッセージにしていきましょう!!

まとめ

  • なぜそのコードを変更したのかが記載されている。
  • パット見で理解しやすい工夫がされている。
  • 必要なコード以外の情報も取得できる。
  • この記事を書いた人

鈴木陽介

株式会社セブンコードの社畜 コンテンツマーケティング事業部の部長! ITパスポートの参考書もうすぐ発売

-blog, 開発