はじめに

大学のサークルで一緒の人が以下のような記事を投稿していたのを見かけました。

僕のコミットメッセージの prefix メモ

なるほど、コミットの種類によってPrefixを使い分け、そのあとに本命のメッセージを書くことによって、コミットの種類を明確化することができるわけですね。

自分は適当に「○○した」とかで済ませていましたが、これだとぱっと見で分かりづらいです。彼のように「Prefix+メッセージ」のような形式にすれば、Prefixでコミットの概要を、メッセージでコミットの詳細を知ることができそうです。

どうやら彼のコミットメッセージにはベースがあるらしいです。自分もこれを参考にして、コミットメッセージを分かりやすくしようと思います。

考えてみた

フォーマット

<type>: <message>

ベース記事では<type>(<scope>)という感じでscopeをつけていましたが、あんまりピンと来ないのでとりあえず考えないこととしました。

将来的にscopeを考慮することが増えてきたらまた考えます。

`type`

今回の企画の肝ですね。これを上手く決めることでコミットの概要が分かりやすくなるはずです。

`ci`

CIとは「継続的インテグレーション」の意味で、コードの変更を自動でビルド・テスト・デプロイする仕組みのことです。GitHub Actionsなどが有名ですね。

そういったCIの設定を変更した場合にこのPrefixを使います。

`docs`

ドキュメントの更新・修正を行った際に使います。

主にはREADME.mdがドキュメントになりますが、開発が大規模になってくると要件定義書とかが含まれる可能性があるので、それらの更新時にも使います。

`feat`

新規で何かを追加した際に用いるものです。

新規機能、新規モジュールなど、とにかく何か新しいものを追加した時に使います。

`fix`

バグの修正を行った際に使います。

バグというのは何処かを書き間違えた程度のものではなく、直すのにある程度手間がかかるものとします(依存関係など)。

ちょっとしたミスを修正した際のPrefixは別に用意します。

`correct`

ちょっとしたミスを修正した際に使います。

「ちょっとしたミス」とは、typoやインデントのミス、誤字脱字、何かの消し忘れなどを指します。

`style`

コード内の空白や改行など、スタイルのみの変更を行った際に用います。

スタイルを変更することでコードが見やすくなり、あとからの保守がしやすくなります。

`perf`

パフォーマンスの向上を行った際に使います。

元々正常に動作していたコードに対し、アルゴリズムをよりよいものに変更したり、無駄な処理を減らしたりといった最適化をした時に用いることとなります。

`refactor`

リファクタリングを行った際に使います。

リファクタリングとは、外部から見た振る舞い、つまり入出力の仕様を変えずにコードの内部構造を変更することです。

すでに動いている機能を停止させず、コードの見通しをよくするために行う作業です。こうしておくことで、業務を続けつつ後からのメンテナンスがしやすくなります。

`test`

テストの追加・修正を行った際に使います。

Gitではブランチ機能があるので、テスト用ブランチを用意して他のブランチに影響を与えないようにしつつテストを行います。

様々な入力を用意し、想定の結果が得られるかどうかをテストとして行います。

`review`

コードレビューを行った際に用いるものです。

コメントの追加などがレビューにあたるかな、と思います。

`update`

何らかのアップデートを行った場合に用います。

パッケージやライブラリのアップデートをしたときに使うことが多いでしょう。

`chore`

その他の変更を行った際に使います。

「その他」と一括りにしてしまうと分かりづらいので、できるだけ使わないようにしたいです。

`message`

英語か日本語。チームに合わせるべきですが、個人開発ならどっちでも良いと思います(英語のほうが勉強になる)。

基本的に短く書き、長くなる場合は2行目を空行としてそれ以降に記述する方式を取ります。

<type>: There is a short summary!

<type>:

There are long messages!
Foo Bar Baz Qux Quux Corge Grault Garply Waldo Fred Plugh Xyzzy Thud...

おわりに

コミットメッセージをフォーマットすることによって、後から見た時に履歴が分かりやすくなって良いと感じました。

チーム開発でならチームの方針に従うことが重要ですが、個人開発などでは今回決めたフォーマットをどんどん利用していこうと思います。

それではまた。

参考文献

僕のコミットメッセージの prefix メモ

angular/CONTRIBUTING.md at 2d8fa73c1d6cce078889548c69b8ddb8e84ac106 · angular/angular