続・Git初心者がCommitの粒度とかを考えた話

前回より

「よし、今日の作業も終わったんやな」
「前回のをもとに、commitして今日の作業終わりやな」

「せや、commitもそこそこできたしどんなになってるか一度確認してみよか」

「…」
「なんかADDばっかやな…」
「よく見ると自動テストもADDやし、参照変更もADDになってしまってるな」
「ADDがごっちゃ混ぜにしすぎてわかりにくくなってるんやな」
「どないしよか…」

コメントでもらったアドバイス

「前回のコメントで色々アドバイスを頂いたなかで、AngularのCommitルールてのを教えてもらったんやな」
「自分で考えるのも大事やけど、偉大な先輩方の考え方をここで見てみるのもてやな」

Angularのコミットメッセージガイドライン

Developing AngularJS - Git Commit Guidelines

• 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

「当然のことながら英語なんやな」
「接頭詞でなんとなく意味はわかるけど、翻訳してみよか」

翻訳してみる

• feat: 新機能の追加
• fix: 不具合の修正
• docs: ドキュメントのみの変更
• style: コードの処理に影響しない変更(スペースとか、書式設定とか、セミコロンの欠落とかの修正)
• refactor: バグ修正や機能の追加を行わないコードの変更
• perf: パフォーマンス改善を行うためのコードの変更
• test: テストの項目抜けや、既存のテストの修正を行う
• chore: ドキュメントの生成や、ビルドプロセス、ライブラリとツールをなどの変更

「こんなもんやろな」
「Google先生はほんと神様やで…」

前回のを修正

「前回でワイが考えたのより思ったより細分化しとるな…」
「しかも、結構きっちりわけられとるし…」
「ワイが前回考えたのも色々不足してる点も見えたし、Angularのルールを元に改良してみよか」
「…参考にして組み込んでもええもんなんやろか…」

バージョンアップする

「前回のワイが考えたのがこれやな」

• NEW
• ADD
• REMOVE
• BUG_FIX

「問題点としてはやはりワイの変更点がADDだけなのは、1つにまとめすぎな気がしてきたんやな」
「現状やとパット見で、どこを修正したのかが結構解りにくいんやな」
「考えてたときは、これで十分やろ！と思ったけど、よくよく考えるとドキュメントやテスト自動化もあったんや…」
「多くなったら分かりづらいやろとか考えたけど、逆にコード以外でもCommitする場合あったもんな…」

「ということで、Angularのルールを参考にしつつADDを分割してみよか」

ADDを分割しよう

「まずは、何が必要かの洗い出しやな」

• 新機能の追加
• 既存機能のアップデート
• リファクタリング
• 自動テスト
• コードの見た目の修正

「こんなもんやろ」
「次はこれらの接頭詞に変えてみよか」

• 新機能の追加
• 既存機能の変更/更新

「これらはすでにあるNEWとADDで対応できそうやな」
「残りのは絶対にADDで対応できひんから、新しいのを考える必要があるな」

• リファクタリング
  • REFACTOR
• 自動テスト
  • TEST
• コードの見た目の修正
  • STYLE

「こんなもんでええやろか」
「ADDの内容を分けれたんやな」
「ただ、ドキュメント作成やライブラリとかツールの追加や更新をするとして、これやとまたADD一択になってしまうんやな」
「ドキュメントは単純にDOCSでええやろ」
「ライブラリとツールの追加や更新は頻繁にせんやろし、それだけで追加しても使用率が低そうなんやな」
「あと、ワイがまだ想定してない細かい事ありそうやしな」
「そういうのは単純に、高度な柔軟性を維持しつつ臨機応変にその他ということでOTHERでええやろ」

「ここまでのをまとめると、こうなったんやな」

• NEW
• ADD
• REFACTOR
• TEST
• STYLE
• DOCS
• OTHER
• REMOVE
• BUG_FIX

「一気に増えたんやな」
「でも、それぞれが何を示すか一気にわかりやすくなったから、これでしばらくやってみよか」

おわりに

「前回はワイ記法で記事を書いてみると、たくさんのいいねとコメントを頂いてとてもありがたかったんやな」
「それで色々アドバイスをいただき、今回の記事でそれらを元にルールのアップデートを行ってみたんやな」
「今回は、Angularのルールをかなり参考にさせていただいたんやな」
「しばらくは、個人プロジェクトでこのルールで動かしてみて、結果をフィードバックしようかな」