はじめに
前回、Git運用記事の第一弾として「コミットメッセージを統一する」という記事を書きました。
今回はその第二弾として「コミットメッセージをチェックする」について書きたいと思います。
記載する内容
- コミットメッセージを統一する ←前回の記事
- コミットメッセージをチェックする ←今回はこれ
- ログ&バージョニングを管理する
目的
コミットメッセージをチェックする目的ですが、もちろん「コミットメッセージが(Semantic CommitsやConventional Commitsの)規約に沿ったフォーマットであるか」をチェックするためです。
詳細は次回書きますが、ログ&バージョニングでは、コミットメッセージが規約に沿っていることが前提なので、規約に沿ってないと正しく動作しません。
また、前回紹介した「cz-cli」や「git-cz」経由でgit commitすれば問題ないですが、ついつい「git commit」や(VS Codeなど)GUIのGit機能経由でcommitを行ってしまうケースも起こりえます。
そういった際にもちゃんとコミットメッセージが規約に沿っていることを保証するために、コミットメッセージをチェックする必要があります。
紹介するツール
husky
huskyは、各種Git Hooksの処理を簡単に作成できるツールです。
GIt Hooksについては下記リンク先を参照。なおコミットメッセージのチェックの場合「commit-msg」だけでOKです。
Git - Git フック
husky自体は直接コミットメッセージのチェックは行いませんが、「git commitした際に、自動でコミットメッセージのチェックを行う」処理を簡単に作成できます。(commitlintでも、huskyとの併用方法が紹介されています)
インストール&使用方法
下記手順で実施します。(下記手順を実施すると、カレントディレクトリに「.husky」というフォルダが作成される)
# インストール > npm install -D husky # npm > yarn add -D husky # yarn # Git hooksの有効化(これやらないとGit hooksを扱えないので注意) > npx husky install # npm > yarn husky install # yarn
なお必須ではないですが、package.jsonに下記scriptを定義しておくと、リポジトリclone&npm(yarn) install時に自動でGit Hooksの有効化処理をしてくれるため便利です。(公式でも推奨されています)
"scripts": { "postinstall": "husky install" }
フックイベントの作成
下記コマンドをすると、Git Hooks定義ファイルが.hooks内に作成されます。(今回はcommit-msgフック用の定義ファイルを作成)
# 「npx(yarn) husky add .husky/(Git Hook) 実行コマンド」の形式。 # $1に実際のコミットメッセージが入る。 > npx husky add .husky/commit-msg 'npx --no -- commitlint --edit $1' #npm > yarn husky add .husky/commit-msg 'yarn commitlint --edit $1' #yarn
ここまでできれば一旦huskyの設定はOKなので、次はcommitlintです。
なお今回は紹介しませんでしたが、よくhuskyと一緒に用いられるツールとして「list-staged」があるので、リンクを貼っておきます。
(commit時にeslintやprettierなどの処理を実行する際に使われます)
https://github.com/okonet/lint-staged
commitlint
commitlintは、概ね名前の通り「commitメッセージのlintツール」で、commitメッセージが規約に沿っているかをチェックしてくれます。
huskyと組み合わせて、以下の処理を書くことで、git commit時にcommitメッセージのチェックを自動で行ってくれます。
- huskyでcommit-msgをフック
- commit-msgのフック処理でcommitlintを実行する
インストール&使用方法
> npm install -D @commitlint/config-conventional @commitlint/cli # npm > yarn add -D @commitlint/config-conventional @commitlint/cli #yarn # windows以外だと、こういう書き方もできるんだね > npm install --save-dev @commitlint/{cli,config-conventional} # commitlint.config.jsファイルに設定を書き込む。 # なお公式ページにある通り、設定ファイルの名前はいろいろある echo "module.exports = { extends: ['@commitlint/config-conventional'] };" > commitlint.config.js
最後のコマンドはcommitlint.config.jsファイルに設定を書き込んている処理なので、自分でcommitlint.config.jsファイルを作成してもOK。
module.exports = { extends: ['@commitlint/config-conventional'] };
また「@commitlint/config-conventional」はConventional Commitsを適用しますが、他にも種類があるので、興味がある人は調べてみてください。(今回は@commitlint/config-conventionalに限定して話を進めます)
なお設定の詳細は、下記ページを参照してください。
https://commitlint.js.org/#/reference-configuration?id=configuration
ルールの設定&カスタマイズ
commitlintで適用されるルールは、下記ページに記載されています。 https://commitlint.js.org/#/reference-rules?id=rules
上記ページを読めば、適用ルール自体は理解できると思います。
また独自のルールを追加することはできない(少なくとも自分は知らない)ですが、既存ルールの設定を変更することはできます。
その場合は、commitlint.config.jsの「rules」に、その内容を記載します。
const Configuration = { extends: ['@commitlint/config-conventional'], /* * ルール変更の例:type(変更種類)の最低文字を1文字にする(=入力必須にする) */ rules: { 'type-min-length': [2, 'always', 1], },
ルールのカスタマイズの方法
ルールのカスタマイズは、先述のように、下記形式で記載します。(関数形式でも書けます)
rule_name = [level, applicable, value]
右辺の配列の項目は、以下になります。
項目 | 説明 | 備考 |
---|---|---|
level | エラーレベルを0, 1, 2のいずれかで記載。 ・0: ルールを無視する(適用しない) ・1: NG時に警告を出す(commitは継続) ・2: NG時にエラーにする(commitも中止) |
|
applicable | ルールの適用方法をalways, neverのいずれかで指定。 ・always: 値が条件を満たした場合、OKとする。 ・never: 値が条件を満たした場合、NGとする。 |
条件は公式ページのconditionを参照 |
value | value(最小値、最大値、数値の範囲など)を受け付けるルールの場合に、その値を設定する。 | valueの有無は公式ページのvalueを参照 |
applicableの例
例えば「type_empty」は「type(変更種類)が空文字であること」をチェックするルールですが、applicableの設定により、下記のような挙動になります。(=真偽が反転する)
- always: typeが空文字の時、判定結果はOKになる
- never: typeが空文字の時、判定結果はNGになる。(=未入力はNG)
というか「xxx_empty」系をalwaysで使うことはまずないと思います。(level=0かnever。デフォルトもそうなってます)
実際に導入する
といっても、導入&コマンドはhuskyのところで書いた通りですし、commitlintの設定は最低限上記に書いた「module.exports=extends: ['@commitlint/config-conventional'] 」があれば動きます。
ここまで出来たら、実際にcommitを実施してみましょう。
commitメッセージがSemantic CommitsやConventional Commitsの規約通りなら正しくcommit出来て、そうでないならばcommitlintが何かしらのエラーを表示すると思います。(例えば「なんか変更」というコミットメッセージ(=typeを指定しない)をcommitすると、エラーになるはずです)
正しく動作すれば、導入は完了です。あとは色々カスタマイズして、運用しやすいように変更しましょう。
まとめ
今回はコミットのチェックについて書きました。
commit時にコミットメッセージのチェックを自動でやってくれるのは、非常に便利だなと思います。(ルール浸透にも役立ちますし)
またhuskyは色々なGit Hookをトリガに処理を実行できるので、コミットメッセージのチェック以外にも色々使えそうですね。
次回は最終回として「ログ&バージョニングを管理する」について記載しようと思います。
それでは、今回はこの辺で。