Conventional Commits

ソフトウェア開発
2021.04.29

Conventional Commitsは、コミットメッセージの書き方を決めて、開発者の意思疎通や自動化ツールの導入を容易にするための仕様です。

Conventional Commitsの仕様は、コミットメッセージのための軽量の規約です。 明示的なコミット履歴を作成するための簡単なルールを提供します、この規則に従うことで自動化ツールの導入を簡単にします。 この規約はSemVerと組み合わせることで、コミットメッセージへ機能、修正、破壊的変更を入れることで、さらに詳細な説明を可能にします。

https://www.conventionalcommits.org/ja/v1.0.0/#概要

コミットメッセージは、次のようなフォーマットで記述します。

<type>[optional scope]: <description>

[optional body]

[optional footer(s)]

例えば、バグ修正を行った場合、次のようなコミットメッセージにします。

fix: 初期値の値を変更(1 -> 2)

<type>が重要で、主としてfix, feat, BREAKING CHANGE(or !)があり、次の意味があります。

  • fix
    コードベースのバグにパッチを当てる場合です。これは セマンティックバージョン管理におけるPATCHに相当します。
  • feat
    コードベースに新しい機能を追加した場合です。これはセマンティックバージョン管理における MINORに相当します。
  • BREAKING CHANGE(or !)
    <body>または<footer>にBREAKING CHANGEが存在する、または、<type>,<scope>の直後に!が追加されているコミットは、APIの破壊的変更を意味します。セマンティックバージョン管理におけるMAJORに相当します。BREAKING CHANGEはあらゆる<type>のコミットに含めることができます。

<type>は他のものも許容されており、build, chore, ci, docs, style, refactor, perf, testなどがあります。
Conventional Commitsの仕様は、AngularのCommit Message Guidelinesに触発されているようなので一度確認すると良いでしょう。

まとめ

この仕様に準拠することで、次のようなメリットがあります。

  • 変更履歴(CHANGELOG)を自動的に生成できる
  • Semantic Version単位で自動的に履歴をまとめれる(コミットされた<type>に基づく)
  • チームメイトや一般のユーザー、およびその他の利害関係者へ変更の内容を伝えることができる
  • ビルドおよび公開プロセスをトリガーにできる
  • より構造化されたコミット履歴を調査できるようにすることで、人々があなたのプロジェクトに貢献しやすくなる

確かにこの仕様によってコミットメッセージから新しいバージョンを決定したり、変更履歴を自動作成できそうです。

コメント