はじめに
業務で感じていて 「1PR1コミットの原則」が、自分にはなぜ合わなかったかについてまとめておきたい。
1PR1コミットの原則
開発の現場で、PRをだしたさいに同期の優秀なエンジニアからレビューをいただいた。
1つのプルリクエスト内では1つのコミットという形がいいよ
純粋無垢な気持ちでレビューを受け入れて、
「なるほど🤔確かにコミット履歴が大量に発生している状況よりも履歴がクリアになってすごくいいな」
と個人的には思っていた....
だが、しかーし。自分には合いませんでした😭
これまでの履歴って全部追えていますか？
あわなかった理由の一つとしてこれがあります。
"他の開発者が記述したmergeした分を完全に記憶していますか？"
答えはNoの方が多いのではないのでしょうか？
自分がこれまでコミットした履歴ならまだしも、他の開発者のコードの差分まで検知して、記述に対する意識意思決定の深い解像度まで握れている方は多くないのでは？と思います。
- 「どこが自分の意図した変更で」
- 「どこがマージやrebaseによって生じた変更で」
- 「どれがいらないノイズか」
これを判断しながら1つのコミットにまとめていくのは限界があるなあと思いました。
タスクの粒度は大きくないですか？
意外と小さい粒度のタスクってなくないですかね？
- ドキュメントの一文を更新する
- 見出しをh2にする
こういう事例のものだとタスクの粒度は小さいと思うので、コミットをrebaseしてまとめるのがよいと思います。
ただ、こういうタスクってレアなケースじゃないかなと思います。
むしろコードを変更するって時間を割いてやる行為。記述を変更することで、インパクトがあるのか？変更の恩恵がないとそもそも変更はかけないと思うんですよね（個人的に）。
自分みたいな怠惰な人間は、インデントごときで変えなくてもいいんじゃねって思ってしまいますw（あくまで個人の主観です）
履歴をきれいにすることが目的になっていない？
ここまできて目的がなんかぶれているなって自分は思いました。
- 履歴がきれいだとどんなメリットがあるのかな？
- 複数コミットってデメリットそんなにあるかな？
「1コミットが正義だぜ！！！」っていう主張は認めます。だけど、目的って本当に履歴をきれいにすることなのか？
これを追求することが大事なのかなと思います。
「他人にとって追いやすく、再現性がある履歴を残すこと」
こっちのほうが大事になってくるのではないでしょうか？
たとえば
- add: ログイン画面のバナーを差し替え
- add: ログイン画面の配色を〇〇styleに適用
こういう感じでコミットしていったほうが追いやすいさ的な目的にはあっているのではないかと個人的には思います。
全員にとって 1コミットにまとめる というのが最善ではない
これはもうトライアンドエラーの世界なのかなと思います。
1PR1コミットの原則がいいよっていっても、無理に1コミットにまとめる必要はないです。
開発者の状況や更新頻度などを通して、客観的に1つにまとめといいと思ったらGoするのがいいやり方なのではないのかなと思いました。
メリットだけではなく、デメリットにもきちんと向き合いたいです。
おわりに
レビューを純粋に受け止めるつつも、自分に合うやり方はなんなのか？
考えながら楽しく開発をしていきたいものです。