導入してよかったこと
gitを使い始めてしばらくしてもコミットに何を書けばいいのか迷う時期がありました。
そこでOSSのとあるJSライブラリ開発ではprefixを付けていることを知り取り入れてみたところ
- コミット内容のカテゴリ付けされているみたいになりコメントの取っ掛かりになる。
- コミットに含める内容を意識しやすくなった。
- prefixを見ればロジックに影響がある変更なのかわかりやすくなった。
- 漠然と使っていても体験すればするほど理解が深まっていく。
という効果を実感してきました。
ただライブラリ開発とWeb開発の違いから補足したところや2,3年使ってみて理解が進んだ部分があったのでそれらも一緒にまとめてみます。
prefix付きコメントについて
コメント例
feat: Validation種類追加のためValidator追加
やってることはこのように prefixは feat: の部分で内容に合うものを付けてからコメントを書くようにするだけです。
元は Angular.js でのcommit format 内の <type> 部分で他にもformatがありますがここだけ導入してもわかりやすくなります。
※この形式が Semantic Commit Messages と命名されていました。
prefix種類
これはコミットを区別するために書くのですがそれぞれどんな時に使うか説明を書いていきます。
-
feat:ロジック・機能(一緒に書いたUnitTestも含む)・ロジックにかかわるライブラリ追加やupdate -
fix:バグ修正(ロジックの変更あり) -
docs:jsdocやphpdocなどのようなコードに影響ないコメント、ドキュメントファイル -
style:コードスタイルの修正のみ(ロジックの変更なし) -
refactor:リファクタリング -
perf:パフォーマンス改善(この変更が注意箇所になる) -
test:UnitTestのみの修正やTestCaseの追加 -
chore:ビルド用のファイルや補助ツール、ドキュメント生成のような関節的なライブラリ関連 -
design:HTMLソース・画像やcssなどデザイン関連 -
remove:機能やファイルの削除(これによるインパクトを意識しないといけない)
参考元
Angular.js
https://github.com/angular/angular.js/blob/master/DEVELOPERS.md#type
付け加えたのは design と remove
design はデザインチームからの素材を取り込んだりする必要があるので区別するため。
remove は運用しながらの開発をしているので削除したことによる影響を考えないといけないため配慮が必要なので追加しました。
環境によってはまた違うprefixが必要になるかもしれませんが
『ロジックに影響するかしないか』や『区別する理由』に気付けるようにすれば良いと思います。