はじめに

業務で感じていて　「1PR1コミットの原則」が、自分にはなぜ合わなかったかについてまとめておきたい。

1PR1コミットの原則

開発の現場で、PRをだしたさいに同期の優秀なエンジニアからレビューをいただいた。

1つのプルリクエスト内では1つのコミットという形がいいよ

純粋無垢な気持ちでレビューを受け入れて、
「なるほど🤔確かにコミット履歴が大量に発生している状況よりも履歴がクリアになってすごくいいな」

と個人的には思っていた....

だが、しかーし。自分には合いませんでした😭

あわなかった理由の一つとしてこれがあります。

"他の開発者が記述したmergeした分を完全に記憶していますか？"

答えはNoの方が多いのではないのでしょうか？

自分がこれまでコミットした履歴ならまだしも、他の開発者のコードの差分まで検知して、記述に対する意識意思決定の深い解像度まで握れている方は多くないのでは？と思います。

これを判断しながら1つのコミットにまとめていくのは限界があるなあと思いました。

意外と小さい粒度のタスクってなくないですかね？

こういう事例のものだとタスクの粒度は小さいと思うので、コミットをrebaseしてまとめるのがよいと思います。

ただ、こういうタスクってレアなケースじゃないかなと思います。

むしろコードを変更するって時間を割いてやる行為。記述を変更することで、インパクトがあるのか？変更の恩恵がないとそもそも変更はかけないと思うんですよね（個人的に）。

自分みたいな怠惰な人間は、インデントごときで変えなくてもいいんじゃねって思ってしまいますw（あくまで個人の主観です）

ここまできて目的がなんかぶれているなって自分は思いました。

「1コミットが正義だぜ！！！」っていう主張は認めます。だけど、目的って本当に履歴をきれいにすることなのか？

これを追求することが大事なのかなと思います。
「他人にとって追いやすく、再現性がある履歴を残すこと」

こっちのほうが大事になってくるのではないでしょうか？

たとえば

こういう感じでコミットしていったほうが追いやすいさ的な目的にはあっているのではないかと個人的には思います。

これはもうトライアンドエラーの世界なのかなと思います。

1PR1コミットの原則がいいよっていっても、無理に1コミットにまとめる必要はないです。
開発者の状況や更新頻度などを通して、客観的に1つにまとめといいと思ったらGoするのがいいやり方なのではないのかなと思いました。

メリットだけではなく、デメリットにもきちんと向き合いたいです。

レビューを純粋に受け止めるつつも、自分に合うやり方はなんなのか？
考えながら楽しく開発をしていきたいものです。