読者です 読者をやめる 読者になる 読者になる

よいコミットメッセージ・よくないコミットメッセージ

こんにちは、mzpです。

今日はMisocaのesaに書いていた「よいコミットメッセージ・よくないコミットメッセージ」という記事を紹介したいと思います。

あらすじ

開発チームでは「コミットメッセージには変更理由を書いて欲しい」「コミットメッセージはWhatよりもWhyが大事」という話を何度かしているのですが、なかなか徹底できていません。

ので、もう少し具体的に「こういうコミットメッセージはよくないですね」というまとめを作ってみることにしました。

ちなみにこの過程でみつけたコミットメッセージに、こんなものがあります。 一切情報がなくておもしろいですね。

f:id:mzp:20170313132724p:plain

ファイル移動を移動した事実しか書かない

これは以下のようなコミットメッセージです。

ファイルを移動したことはコミットメッセージを見なくてもdiffから分かりますが、なぜその移動をしたかが分かりません。 ので、移動した理由を残すようにするとよいです。

  • 責務を適切に表わすファイル名に変更
  • ライブラリのバージョンアップに伴いディレクトリ変更
  • 似た内容のファイルをまとめるためにディレクトリ移動

「指摘対応」としか書かない。

これは以下のようなコミットメッセージです。冒頭にあげたコミットメッセージもこれですね。

  • レビュー対応
  • 指摘対応
  • Rubocop対応

なぜその変更をしたかが後から見たときに分かりません。 指摘があった場合はその内容を残すとよいです。(参考: 自分の言葉で書かれたコミットメッセージが好き - 準二級.jp)

  • 一行が長すぎるので修正
  • Style/IndentHash による自動修正
  • メソッドが長すぎるので修正
  • Array#map を使ってリファクタリング

「修正した」としか書かない

これは以下のようなコミットメッセージです。

  • specを修正
  • CI対応

繰り返しになりますが、なぜその修正をしたかがあとから分かりません。 CIやspecで確認していることをコミットメッセージに残すとよいです。

  • xがnilのケースを想定していなかったので修正
  • specが意図したものになっていなかったので修正
  • CIでの実施内容が間違っていたので修正

コミットメッセージに理由を書こう

Misocaではコミットメッセージに理由を書くエンジニアを募集しています。