「Gitのコミットメッセージをしっかり書こう」という記事を読んで、いい話だなーと思う一方で、うちのチームはちょっと前に「コミットメッセージは適当でいこう」って決めたなーって思った。
Gitのコミットメッセージをしっかり書こうという話【備忘録的共有】 | SIOS Tech. Lab
しっかり書くのを否定するわけでは全然ない。しっかり書くのはしっかり書くのでいいなって思う。どっちがいいかはチームやプロダクトによるので、チームがいいと思う方を選べばいいかなと。
僕もしっかり書くほうがいいなって思うときもあるのだけど、今のチームでは適当のほうがいいなってだけ。
しっかり書きたいとき
僕が、コミットメッセージをしっかり書きたいときはどういうときだろう？って考えると、OSSにプルリクエストを出すときかなぁ。自分は特にOSSの何かを作ってるわけじゃないけど、自分で何かのOSSを作るならある程度ちゃんとコミットメッセージを書きそう。
そういう、背景を共有してない人たちが見るプロダクトには、ある程度しっかりコミットメッセージを書いておきたい。これは、OSSに限らず、仕事で社内の色んな人たちが使うようなものを作るときや、別のチームのプロダクトにプルリクエストを出すときもそうかな。
適当でいいとき
適当でいいなって思うのは、仕事で自分のチームが開発・運用してるプロダクトのとき。
- コミットメッセージを考えるのに時間を使わない
- コミットをキレイに整えることに時間を使わない
- 変更の理由や意図は、プルリクエストで伝える
な感じ。
前提にあるのは、こういうところ。
- コミットの粒度が小さい。書いてる途中のドキュメントをセーブするくらいの気持ちでコミットする。push前にまとめたりはするけど。
- プルリクエストの粒度も小さい。2,3日くらいで出す
- 仕様に対する「なぜ？」の部分は仕様のドキュメントに書いてあって、コードを書くより前に認識合わせをしてる
- 実装に対する「なぜ？」の部分を書いたほうがいいなと思ったら、コミットメッセージじゃなくて、コードのコメントに書く。そのほうが読みやすい
- 複雑な意図や理由がある場合は、事前に共有してチーム内で意見を交換している
- そもそもペアプロとかして一緒に進めてる
なので、今のチームではコミットメッセージは適当に書いてる。
コードレビューでは、コミットメッセージにちゃんと書いてなくても意図が事前に共有できている状態だし。未来に参加する人に対しては、コミットメッセージじゃなくて、ドキュメントやコード自体で意図を残してる、って感じかなー。