Sendagaya.rb #297 に参加させていただきました
はじめに
最近月曜日の恒例になりつつある、Sendagaya.rbに参加させていただきました。
「勉強会に、ただ参加するだけではなく、もっと積極的に参加したい」、「自分も何か皆さんに投げかけられるような話題を持っていきたい」という思いが強くなり、今回は、自分が日頃の学習で悩んでいた「コミットの粒度がわからない」という問題を持っていきました💪
皆さん、とても優しく、教えてくださりとても有り難かったです😆
今回は、そこで学んだことをまとめたいと思います💪
コミットの粒度がわからない問題について
実際に、皆さんにお見せしたコミットログは以下の通りです。
そもそも何のためにコミットがあるのか？
私は、この部分を考えたことがありませんでした。自分のセーブポイントくらいにしか思っておらず、この話題が出た時は、ハッとしました。実際に議論された内容は以下のような感じです。
- 誰かに見せるため。
- 後からコミットログを見直して、どのコミットが悪かったのかを探るため。
- (自分が分かりやすいように)
3の優先順位は高くなく、1・2がコミットが必要な理由とのこと。そのため、1・2を基準にして今回のコミットの良し悪しを考えていくと・・・
レビュワーの立場に立って考えてみるべし
1を考えた時、レビュワーが見やすくするようにコミットを作るのが大切という話がありました。
そして、レビュワーの立場で立つと、PRを見てから、コミットログを見るという見方があるようで、それを考えると、コミットはPRありきで、PRとコミットが合わせて理解できるようになれば良いのでは？というお話がありました。
仮に、コミットが大量だと、いちいちコミットを追っていくのが、面倒になるため、PRとコミットが合わせて理解されれば良いと考えると、コミットはそこまで細かくある必要はないのでは？といただきました。
このPRありき、という考え方が自分にはなかったです。「コミットだけで意味が伝わるようにならなければ・・・」という意識が自分の中にはありました。
これは、新しく意識が変わったところでした。
自分のコミットログは？
今回は、自分のコミットログは細かすぎるのではないかということになりました。
ユーザーフォロー機能であれば、もっとコミットが大きくても問題はないのではないかということでした。
実際に、参加者の方のコミットログを拝見したのですが、しっかりとまとめられていて、コミットが4つくらいでした🤭
どういう風にコミットをしていく？
具体的な方法としては
rails gしてマイグレーションしたら、コミットする分かりやすい、大きな変更のコミットを作っておいて、細々としたものは
git rebaseでfix up していく。細かいコミットを積み重ねて、あとで、
git rebaseでコミットをまとめる
コミットメッセージの書き方としては
これは伝えた方が良いということ(変更の見方、こう見ると変更が見やすいですよなどというレビューのガイド)をコミットメッセージに書いておく
Fixは何が悪かったのかをかく
コミットログにはwhyをかく
などなどが挙げられました。
まとめると
このコードをレビューする人の立場になるということを、私は考えたことがありませんでした。
また、コミットが何のために存在するのかということも深く考えていませんでした。
私はまだ現場にも出ていないため、レビュワーの方がどのような観点で見るのかということを理解するのは難しいですが、自分なりに想像してみることが必要だと思いました。
上記のような具体的な手順を実際に実行して、自分なりにレビュワーの人の立場に立ってコミットしていきたいと思いました💪
とても、学びが多かったです。参加者の皆さん、ありがとうございました🙇♂️🙇♂️
