プルリクベースの開発ではコミットはテキトーで良いN個の理由
きよしろーはじめに
チーム開発で「わかりやすいコミット粒度、コミットメッセージにしましょう」というのはよく言われる。しかし、以下の条件を満たす場合は、コミット粒度もメッセージもテキトーで全く問題ない可能性がでてきたので理由をメモしていく。
条件
- プルリクベースで開発を進めている
- プルリクのタイトル・本文をきちんと書いている
- 「レビューしやすいように、1プルリクはなるべく小さく」という文化がある
(おそらくほとんどの開発チームで満たす気がする🤔)
スクラップの流れとしては、一般的にコミットメッセージをテキトーにした場合に起こると思われている以下のデメリットが実はそうではないことをメインに書いていく。
- レビューがしづらくなる
- マージ後、あとで変更意図が追えなくなる
- mainブランチの履歴が汚れる
きよしろーよくある誤解1: レビューがしづらくなる
「1プルリクはなるべく小さく」という文化があれば、コミット履歴など読まず、ファイルの差分を見てレビューを行っても何ら支障はない。
もちろん、大きなプルリクであれば、適切な粒度でコミットが分割されて、一つ一つのコミットにわかりやすいメッセージを書くことで、レビューしやすくなるとは思う。ただ、「レビューがしやすいコミット履歴をつくる」のは実は果てしなく難しいということに気がついていない人が多い。
レビューがしやすいコミット履歴の作り方
- チームでコミットの粒度の認識を合わせる(これがもう激ムズ)
認識があっていないと、レビュー時にコミット履歴を追っても、「なんか自分の読みやすい粒度と違うなー。もうFile Change読むか」となってしまう。 - 1のコミット粒度になるようにコミットをする。
なんだかんだ1発で想定通りの粒度にならないことが多い。git rebase -iでコミットをまとめたり分割するテクニックが必要になりがち(これがムズい) - 普通のgit pullをするとマージコミットができてしまってコミット履歴が汚れるので、場合によっては
git pull --rebaseなどを使う(ここでコンフリクトすると解消がややこしい)
git rebaseは学習コストが高いし、コンフリクト解消もややこしい。他の技術の学習とコーディングに時間を割いたほうが賢明な気がしてならない。
まとめると、
- コミットの粒度に気をつけてメッセージを頑張って書いても、労力に見合うほどレビューしやすくならない。
- 本当にレビューしやすくなるようなコミット履歴をつくるのは想像の100倍難しいので、最初から諦めて1プルリクを小さくするのを頑張ったほうが良い
きよしろーよくある誤解2: マージ後、あとで変更意図が追えなくなる
「この行なんで追加されたんだろう？よし、git blameだ」としたときに、コミットメッセージがきちんと書かれていないと変更意図がわからないと思われる方もいるかも知れない。
しかし、「その行が最後に変更されたプルリク」は簡単に特定できる。
↓はVSCodeのGitLens拡張機能を使った例。マウスを当てるだけ。
GitHubのBlame画面でもプルリクの特定は簡単にできる。
つまり、プルリクのタイトル・本文をきちんと記載していれば、あとから変更履歴は追える。
きよしろーよくある誤解3: mainブランチの履歴が汚れる
たとえば、squashマージをしてしまえば、1プルリクが1つのコミットにまとまるので、履歴もきれいになる。
squashマージ運用の問題点として、「意図せぬコンフリクトが発生しまくる」というのがある(これが理由でsquashマージを敬遠する人もいる)。
以下の記事が非常にわかりやすい。
この記事にあるように、実はsquashマージをせず、普通のマージだったとしても
git log --first-parent
すれば、squashマージした時みたいな、きれいな履歴は得られる。
つまり、コミットはテキトーにして良いし、普通のマージでも何ら問題ない。
本当に整えるべきはプルリクの本文である。
きよしろーTODO:
自分のチームで、「コミットはテキトーで良い」という方針でやってみてなにか課題が出てこないか確かめる