echo("備忘録");

IT技術やプログラミング関連など、技術系の事を備忘録的にまとめています。

【Git】コミットメッセージを自動でチェックする

はじめに

前回、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をトリガに処理を実行できるので、コミットメッセージのチェック以外にも色々使えそうですね。

次回は最終回として「ログ&バージョニングを管理する」について記載しようと思います。

それでは、今回はこの辺で。