コミットメッセージと​コミットの​粒度に​ついて​思った​こと

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

見た。以下感想。

思ったこと

コミットメッセージが結構雑になる問題ってのは、自分が考える中としてコミットの粒度が割とデカい場合になるんじゃないかなと思ってる。

例えば数ページマークアップしたときに、ページごとにコミットを切るよりかは、全ページの作業をコミットさせておく方が分かりやすいし、どこまでの進捗なのかも一見しやすいかなと思う。もちろんページ内で機能が複雑化している場合はその限りではないと思うけど。

なのでコミットのメッセージを分かりやすく書く、ということと同時にコミットの粒度をどれほどのものにするか、という意識と進め方を持たないとこの辺はなりたたないのではないかなーと個人的に感じている。

基本業務の流れとして、バグや機能追加の課題が振られてそれらを対応完了するまでを１コミットとしているけど、LP などページ単位で対応するときは、場合によっては、１ページ単位でコミットを切ることがある。

あと良くない癖なので直さなきゃなんだけど、その日に対応する修正もまとめて対応して「00/00 対応分修正コミット」とかで切って細かく書かなかったりもする。修正範囲の意義を全体的なものとして捉えていると、修正する１機能というよりかはそれに付随するもとしてまとめて対応しないと、という意識になっちゃうのでその辺は進行管理とも付随する問題かなと感じる。

この辺の粒度対策としては、ブランチをいかに細かく切って作業するかにかかってるんじゃないかと思うので手を動かす前にまずブランチ切っとけ、終わったらマージしとけを工程の中に入れておかんと危ないなとは感じた。まあもし単位がデカくなってもやり直しが一応できるのが Git の良いところではあるけど、出来る限りそういう修正はしたくないよね、と。

課題の建て方としてもそうだけど個人としては、もう少し部品化・機能化するイメージで進めてみてもいいかなと感じた。この辺は実験として新規のプロジェクトとか、個人がメインで動いていたプロジェクトにもっかいアサインしたら試してみようかなと思ってる。誰かとやるんであればその時のルールには従います。

余談

昔、コミットの内容なんか見なくてもファイルの内容みればどうなったか分かるだろみたいな言説を聞いて、当時はまあそうだよなと思ったけど、結局属人性を加速させかねない危険な発言だったと徐々に分かってきて、１回限りではない・他人の手にも渡るリポジトリ内では、出来る限りは詳細的に書くように努めたいと思ってる。

こちらからは以上です。