Conventional Commits についての覚書

🍩はじめに

ちょいちょいコミットメッセージ型の規約を間違えるので整理しておく。
Semantic Versioning についても少し絡める。

Table 1. 環境
App	Version
Conventional Commits	1.0.0
Semantic Versioning	2.0.0

それぞれの導入目的

Semantic Versioning の目的

依存性地獄に陥るのを防ぐためのバージョン番号に関する規約。
依存性を安全に管理することに役立つ。

Conventional Commits の目的

コミットメッセージのための規約。

変更履歴 (CHANGELOG) を自動的に生成できます。

semantic version 単位で自動的に履歴をまとめられます (コミットの型に基づきます)。

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

ビルドや公開の処理をトリガーできます。

より構造化されたコミット履歴を調査できるようにすることで、人々があなたのプロジェクトに貢献しやすくなります。

— 何故 Conventional Commits を使うのか
Conventional Commits （CC BY 3.0）

🚋Conventional Commits と Semantic Versioning の関係図

特に指定がない限り、ここでの API とは パブリック API のことを指す。

🐕Semantic Versioning

Example 1. バージョン 1.2.3 の場合

API に後方互換性のない、破壊的な変更があったとき。

API の後方互換性を保ったまま、新機能を追加もしくは機能を廃止したとき。

API の後方互換性を保ちつつバグの修正を行ったとき。

🐈Conventional Commits

Example 2. Conventional Commits の形式

type(scope): subject  (1)(2)(3)

body     (4)

footers  (5)

1	コミットの型。後述する型のうちどれかを指定する。
2	本コミットで影響を受けるライブラリやパッケージ名。
3	コミットのタイトル。コード変更の要約。
4	コミットの本文。コード変更の詳しい説明。
5	本文以外での追加情報を書いたフッター。 `<token>: <description>` の形式（ex. `refs: #123`）。

Commit Type

Table 2. Conventional Commits 規約
Type	Description
feat	新機能の追加や機能の廃止。
fix	バグの修正。
! BREAKING CHANGE:	API の破壊的な変更。

BREAKING CHANGE

API の破壊的変更が伴うとき、コミットは次のうちどちらかにする。

(scope) 直後の位置に ! を追加（ex. chore(deps)!:, feat! ）
フッターに BREAKING CHANGE: <description> を追加

上記に加え、よく使われる型はAngular の規約やcommitlintを参考^[1]に下記のようになる。

Table 3. 上記以外によく使われる型
Custom Type	Description
build	ビルドシステムまたは外部依存関係に影響を与える変更。
chore	その他の変更。
ci	CI 設定やスクリプトの変更。
docs	ドキュメントのみの変更。
perf	パフォーマンス改善のためのコード変更。
refactor	バグ修正や新機能のコードを含まない、リファクタリングによる変更。
revert	`git revert` などによって以前のコミットに戻した場合。
style	コードの動作には影響しない、コードのフォーマット変更。
test	テストの追加や修正。

バージョンアップについて

基本的に feat や fix 以外の型ではバージョン番号を上げない。
ただし、revert で機能が廃止された場合はバージョン番号を上げるべき。