commit typeは誰に向けたものなのか

こんにちは。HRBrain でフロントエンドエンジニアをしている山本です。 今回は git commit の commit type についての考えを紹介します。

refactor や feat など、果たして誰に向けた commit type なのか、分からなくなってしまうことがよくあります。
多数の人間が介在するプロジェクトにおいて、ここの考えがまとまらないと、feat なのに refactor といった自体になってしまいます。 今回は commit type のおさらいと、誰に向けて書けば良いのかの整理をします。

git commit message にフォーマットを設定する

commit message をあるフォーマットで統一すると、

  • 見やすさの向上
  • 外部ツールとの連携(commit message を元に document を生成するなど)

などが可能ではないかという声が上がり、さまざまなフォーマットの提唱が各地で発生しました。

以下にいくつかの commit message のフォーマットを挙げます。

今回は、この中でも特に有名ではないかと思われる Conventional Commits に基づいた話をしていきます。
Conventional Commits が公式で日本語訳を提供しているので、詳細な説明はこちらに譲ります。

commit type の種類

Conventional Commits では、fix feat以外の type は自由とされています。
今回は、Conventional Commits で紹介されているcommitlint/@commitlint/config-conventionalでの type を利用します。
conventional-commit-typesに、これら type の説明が記載されているので、こちらも利用します。
日本語訳はこちら こちらを参考にしました。

- feat
    - A new feature
    - 新機能
- fix
    - A bug fix
    - バグ修正
- docs
    - Documentation only changes
    - ドキュメントのみの変更
- style
    - Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc)
    - フォーマットの変更(コードの動作に影響しないスペース、フォーマット、セミコロンなど)
- refactor
    - A code change that neither fixes a bug nor adds a feature
    - リファクタリングのための変更(機能追加やバグ修正を含まない)
- perf
    - A code change that improves performance
    - パフォーマンスの改善のための変更
- test
    - Adding missing tests or correcting existing tests
    - 不足テストの追加や既存テストの修正
- build
    - Changes that affect the build system or external dependencies (example scopes: gulp, broccoli, npm)
    - ビルドシステムや外部依存に関する変更(スコープ例: gulp, broccoli, npm)
- ci
    - Changes to our CI configuration files and scripts (example scopes: Travis, Circle, BrowserStack, SauceLabs)
    - CI用の設定やスクリプトに関する変更(スコープ例: Travis, Circle, BrowserStack, SauceLabs)
- chore
    - Other changes that don't modify src or test files
    - その他の変更(ソースやテストの変更を含まない)
- revert
    - Reverts a previous commit
    - 以前のコミットに復帰

この commit type は誰に向けて付ければ良いのか

Conventional Commits には、以下の文言が出てきます。

コミットにはあなたのライブラリの利用者に思想を伝えるために、次の構造要素を持ちます

チームメイトや一般のユーザー、およびその他の利害関係者へ変更の内容を伝えることができる。

つまり、commit message を書く目的は、

  • アプリケーションを利用する人に機能の告知として書く
  • アプリケーションを開発する人に実装の共有として書く

と分けられることができると私は考えます。
他にも視点があるかもしれません。
しかし大事なのは、commit message は誰に向けたものなのかの軸を決めて統一性をもたせるということです。

この視点を忘れて軸がブレてしまうと、type を付ける基準がブレてしまうと言った事態が発生します。

プロダクトの開発体験を上げるツールの導入を feat として commit

例えば、コードのクオリティを上げるツール、(Lint や scaffolding ツールなど)を導入したとします。
開発側としては、新しく機能を追加するわけですので feat と付けたくなります。
しかし、アプリケーションを使う側としてはこの機能には触れない、関係がないので、アプリケーション利用者にとっては feat ではありません。chore や build などです。

型を type に切り出したので、refactor として commit

アプリケーションが TS の型を提供しているとします。
もっと可読性を上げたいという意図で、型を object にベタ書きしていたものを、type に切り出したとします。さらにその型をついでにexport することとしました。 開発側としては、可読性を上げるためにコードを改修したわけですので、refactor として commit したくなります。 しかし、アプリケーションを使う側としては型が export され使えるようになったので、機能が追加されたという意味で feat です。

まぁ、型の改修と、export した作業を commit 分けろという話にもなりますが・・・

結論

commit type を付ける場合は、誰に向けた commit を終始徹底するのかで書き方が変わってきそうです。
npm には、commit message を書くための支援ツールcommitizen/cz-cliがあります。
commit に統一性をもたせたい場合、こういったツールを使うと捗ります。

最後に

HRBrainでは、React.jsを用いたアプリケーションの開発の他にも、開発者体験改善の作業も並列で行っています。 アプリケーション以外にも、ツールを導入したり作ったり、新しい考え方を持ち寄ったりして日々の業務効率を改善することに興味があるフロントエンドエンジニアの方、Wantedly見ていってください!!!!どうかお願いします!!!!!!!

www.wantedly.com