前回の記事のラストに「良い PR に含まれるもの」として「適切な粒度のコミット」を記載しました。
適切な粒度のコミット…言葉にすると「そりゃ大切だよね！」となりますが、実際は適切な粒度のコミットを作るのは難しいですよねｗ
今回は「どうやって適切な粒度のコミットを作るのか？」ではなく、「自分はどれくらい適切な粒度のコミットが出来ているのだろう？」を振り返るために改めて自分のコミットログを見直して反省する回を開いてみようと思います…！！笑
(その前に…!) 接頭辞
自分はコミットメッセージには Angular.js/DEVELOPERS.md に記載がある下記の接頭辞を使っているので、事前に書いておきます！
### Type
Must be one of the following:
- feat: A new feature
- fix: A bug fix
- docs: Documentation only changes
- style: Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc)
- refactor: A code change that neither fixes a bug nor adds a feature
- perf: A code change that improves performance
- test: Adding missing or correcting existing tests
- chore: Changes to the build process or auxiliary tools and libraries such as documentation generation
接頭辞をつけることの利点は「コミットの内容がわかりやすくなる」という利点だけでなく、「機能を接頭辞の type 単位で切り分けるようになる」という効能もあります。
たとえば、
- feat である機能の追加
- refactor であるリファクタ
上記はそもそも対応内容が違うので、コミットは分けられそうですよね？
こういう実装があるときに、接頭辞をつけてコミットする癖があると、しっかり機能追加とリファクタを分けてコミットをするようになります。
そのため、レビュー時にコミット単位でレビューが出来るようになります。
また、後々機能の変更があった場合に、新規で機能変更の追加コミットを行った後、以前のコミットと rebase することで一つの機能変更のコミットにまとめることができるようになります。
このようにすることで、多少大きな PR になったとしても、コミット単位でレビュー（セルフレビュ含む）を出来るようなるため、確認コストを下げられ、接頭辞をつけるのは凄いオススメだなと思っています。
俺のコミットログ 50 件
# 仕事で使っているリポジトリで下記を実行
git log --author=matinana -50 --oneline --no-merges --no-decorate
（実装内容に関してまずそうなところは xx に変更しています 🙏 xx が多い…笑）
7acabba389 refactor: 処理を共通化
8c7f90d214 style: xxのないパートナーの場合の注意文言を追加
609228789b feat: パートナーの場合のxx取得処理では最後に作られたxxを取得する
faefabde92 style: ディスプレイが小さい端末にあわせてスタイルを追加
870220fa50 style: モーダルにスクロールを追加
8434fe4298 docs: テキスト修正
d837c9165a style: ボタンが3つある場合にあわせてスタイルを変更
fbbf290857 feat: 一部のケースでURLコンポーネントを表示出し分けする
aede94c2a5 style: モーダルデザインを変更
525201bb40 style: 画面のsp表示を作成
71b9461cb0 refactor: 表示されないステータスの処理を削除
e72588099b refactor: 表示されないUIを削除
46553d04a0 chore: update zengin_code 2022_10
d87ad9838e refactor: 不要になるモバイルの分岐を削除
0cc2396534 refactor: ABテストで使っていた不要な分岐を削除
01e4b77a21 refactor: 固定値を返していた不要なメソッドを削除
5a0d3738c1 refactor: 不要なコードを削除
e9ae09216d style: ログイン後の表示にあわせて未ログイン時の表示を変更
1b93904fbd style: figmaにあわせてスタイルを変更
373264059f refactor: 不要なコードを削除
d85d7bec05 feat: xx申請処理時にデータレイヤーにxxに関する情報を渡す
0a1628f476 fix: 都道府県バッチが有る際のリンクを修正
69efe3e8cc feat: spの場合にデザインが未作成のコンポーネントを非表示にする
303e70bdc7 feat: xx編集できない旨のボタン表示をxx承認後は非表示に
5b3f259830 docs: 再提出理由を変更
d9f7534d69 docs: メール内容を変更
0f0c0d31f1 style: ダッシュボード内の要素を修正
27adbfc4a5 style: ラジオボタンのスタイルを変更
9328dcb8cb feat: 特定のケースでxxに関する注意を表示
fce6a5ddca feat: xxの審査をxx文言を追加
0b3585e52a feat: xx後にxxした場合、公開までに必要なことの情報を変更
2dc6c28448 feat: xx後にxxする場合に表示される画面を追加
4569093465 feat: xx以降にxxがされたかを評価するメソッドを追加
f065811506 feat: xx公開予約済みの場合の表示を変更
23c185f9f0 feat: xx公開までに必要なことの分岐にxxが予約済みの場合を追加
2069ef276b feat: プロジェクトが公開可能期間以外の場合のダッシュボードデザインを変更
d5951ab407 docs: 不要な表示を削除
846da1783b docs: xx画面の文言を変更
1dc1308a4a fix: PCとSPの表示を共通化し、変更が必要になる部分のspecを修正
1d5367818b feat: xx編集不可のボタン文言をxxステータスによって変更
2d6d0cb0f3 feat: モバイルの場合は提出期限の文言を改行して表示
2502784efa style: SP用にスタイルを調整し、PCも合わせて修正
c229e9036f chore: 不要になるメソッドを削除
a1ff979d37 stlye: ルートコンポーネントのクラス名をユニークな名前に変更
bf149ec46e refactor: コンポーネントの表示ロジックを修正
3232ac1af1 feat: xxの確認コメントを変更
93f519829e fix: xx済かつあとでアップロードを選択した際の進捗率評価を変更
10a49ee6e0 test: xxがxx済みの場合のxxのsystem_specを変更
224a4a5d9b feat: xxの場合にxxをxx起因でxxしないように変更
3118cd352a feat: xx時の挙動を追加
振り返り
上記のコミットログから頑張って振り返ってみます！
⭕️ 接頭辞自体はすべてのコミットに付与されている
こちらは良い結果だと思います！
コミットメッセージを読んでも、接頭辞と大きく違和感のあるメッセージもないかと思うので、スコープを切り分けた実装は意識出来ている気がします！
⭕️ 接頭辞のバランスもそんなにおかしくなさそう
バグ fix である fix 自体もそんなに多くないので、実装時に追加してレビューで指摘されて fix したケースなどはあまりないように思えますね！
勿論既存エラーの fix 対応のチケットを担当する場合などは fix の接頭辞が付くはずなので、fix があるといけないというわけではないのですが、そうでない場合は fix が少ないというのは修正が少ない機能開発が出来ているという指針になるかもしれないとふと思いました。
また、test の接頭辞が少ないのも良いと思っています。
私は実装時にテストはほぼ網羅させるタイプですが、機能開発と一緒にコミットを積むようにしているので、基本的には feat や refactor にテストコードが含まれていると思います。
勿論、既存の足りていないテストを拡充する際などは、test の接頭辞をつけてコミットを積むので、test が多いことが必ずしも悪いことではありません。ただ、今回のコミットログでは feat が多い中で、test が少ないので、テストと一緒に開発をして、出戻りの少ない開発が出来ているということかもしれません！！？
⭕️ 意味の不明なコミットメッセージがない
よくあるあるなコミットログの一つに
- fix review
- wip
上記のようなコミットログが頻発している PR などもありますが、こういう「結局何してるの？」みたいなコミットログが一つもないことは良い点だと思います。
❌ コミットメッセージの抽象度が高いコミットがいくつかある
上で「意味不明なコミットログがない」といっていますが、下記のように抽象的なコミットログはあります。
- refactor: 処理を共通化
- refactor: 不要なコードを削除
- style: ダッシュボード内の要素を修正
たとえば一番上の「処理を共通化」は、なんの処理を共通化したのか？なぜ共通化したのか？を書くと、よりレビューしやすいと思いますし、「不要なコードを削除」もなぜ不要なのか？があるとレビュアーがコードから不要な理由を読み解く必要がなくなります。
また、セルフレビューという観点からも「あーこの理由で不要ってことは、あの部分も不要かも！」と再発見出来ることもあります。
「抽象度の高いコミットメッセージにしない」この点は次回以降の課題にしたいと思います。
と、ちょっと変わった企画をやってみました。笑
最近色んな物事の振り返りって大切だなと思っているのですが、改めて「接頭辞」や「抽象度」などの指針があることで、コミットログからでも振り返りが出来ると気づいたのは本当に面白いなぁと感じます。
PR に乗せる情報や、コミットメッセージの付け方など、コードに乗らない情報でも日々試行錯誤しながらアウトプットを作っていると、そこからふりかって学べることって本当に無限大なんだなと感じました。
日々考え抜いた上のアウトプットを続けて、一つ一つアウトプットの精度を高めていきたいと感じます。
みなさんも素敵なコミットメッセージと共に Happy Hacking!