Conventional Commitとは
概要
Gitのコミット粒度はまずConventional Commitsで種類が混ざりにくいようにしつつ、「小さいコミットを後からくっつけたり並べ替えたりする方が、大きいコミットを後から分割するよりもずっと簡単なので、迷ったら細かくコミットして後から見直せばいいよ」とよく言っていますhttps://t.co/ySrZSP2xQ7
— Takuto Wada (@t_wada) 2021年12月3日
t_wadaさんが以前Twitterで言及されているのを見かけて、Conventional Commitなるものがあることを知りました。
Conventional Commitとは、以下のようなコミットメッセージの規約を指します。
Conventional Commits の仕様はコミットメッセージのための軽量の規約です。 明示的なコミット履歴を作成するための簡単なルールを提供します。この規則に従うことで自動化ツールの導入を簡単にします。 コミットメッセージで機能追加・修正・破壊的変更などを説明することで、この規約は **SemVer**と協調動作します。
引用元:https://www.conventionalcommits.org/ja/v1.0.0/
形式
Conventional Commitは以下の形式を取ります。
型はfeat
やfix
、docs
など、変更を端的に表した単語です。具体的には次のようになります。
RubyMineでのサポート
www.conventionalcommits.org
にもある通り、Conventional Commitをサポートするためのツールはかなりたくさんあります。所詮はコミットメッセージなので、人力で入力してもConventional Commitにはできるのですが、型やフッターを選択肢から選べたり、枠が決まっているので形式を意識せずにメッセージを作れたりするので、あった方が何かと便利です。
このページにもInteliJ用のツールは掲載されているのですが、私は別途「Conventional Commit」というツールを使っています(RubyMineのPluginストアで評価が高いのを選んだだけ)。
plugins.jetbrains.com
Conventional CommitでCHANGELOGを作る
で、ここからが今回の本題で、Conventional CommitからCHANGELOGを作成します。
何故-conventional-commits-を使うのか には、理由の1つに
• 変更履歴 (CHANGELOG) を自動的に生成できます。
とあって、どうやって自動生成できるのかなと思ったんですが、コミットメッセージが規約に則っていることで、別途ツールを使用すればCHANGELOGにCHANGELOGが作成できるということのようです。
今回は以前リリースしたGemのCHANGELOGを作成してみることにしました。
conventional-changelog
Conventional Commitから色々やるためのツールが、conventional-changelogとしてまとまっています。
github.com
この中のconventional-changelog-cliを使用してCHANGELOGを作成します。
github.com
インストール
conventional-changelog-cliはnpmなので、まずはインストールします。
リリースのためだけに$1を汚したくないので、グローバルインストールします(グローバルを汚すのはいいんかい)。
コマンド
conventional-changelog
コマンドで実行します。helpを見ると分かる通り、結構色々なオプションがあります。
実際に作ってみる
今回はESLint形式で、CHANGELOG.mdに対して追記をしていきます(なんでESLintにしたかというと、ESLintが一番よく知っているパッケージだからというだけです、すみません😅)。
このコマンドを実行してできたCHANGELOGがコチラになります。
Closing Keyword を使ってIssueをクローズしていると、参照先のIssueも表示されるみたいです。これは結構便利ですね。
PRをもらった場合にどうするか?
そのOSSにコミットする人がみんなConventional Commitを使うかというとOSSの場合はそうもいかないと思います。
私も実際にそのケースに出くわしたのですが、「今回は特例で手動でCHANGELOGを追加するか」ということで、特に調べず終わってしまいました。
で、この記事を執筆する過程で調べてみたところ、以下の記述が見つかりました。
www.conventionalcommits.org
いいえ! Git で squash ベースのワークフローを使用する場合は、主要メンテナがマージ時にコミットメッセージをクリーンアップすることができるため、臨時のコミッタには作業負荷がかかりません。 また、これをするための一般的な方法としては、プルリク$1トからのコミットを git システムが自動的に squash し、主要メンテナによるマージ時に適切な git コミットメッセージを入力するためのフォームを表示するというものです。
Conventional Commit側の主張は、「メンテナが都度直せばいいじゃん」とのことでした…。他のRailsとかどうしているんだろう?それこそRailsのような大きなRailsだとなかなか難しいと思うんですが。
感想
というわけでConventional Commitで自動的にCHANGELOGを作る方法でした。
個人的にはコマンド1つでCHANGELOGが完成するので、気楽にupdate作業をできていい感じです。
PRのマージコミットメッセージの件も含めて、他のOSSがどんな感じにCHANGELOGを書いているのかがすごい気になったのですが、残念ながら作成する過程は見えないので、地域rbとかで聞けたら聞いてみようと思います。
余談:もう少しコミットは細かく積もうかな
少しずれるのですが、最近ちょっと前に以下の動画を見た影響もあって、「できるだけコミットはsquashしておこう」と強く意識しすぎていました。
www.youtube.com
そうすると、なかなかコミットが打てなくて作業的には辛いので、
- 作業時はconventional commitでこまめにコミットを打つ
- Pushするときにsquashする
みたいなフローにしたほうがいいなと記事を書いていて思いました。