BREAKING CHANGEフッター
Conventional CommitsでBREAKING CHANGEフッターを使用して破壊的変更を詳細に説明する方法。複数行のコミット本文との組み合わせ。
Breaking Changes
詳細な説明
BREAKING CHANGEフッター
BREAKING CHANGEフッターは、コミット本文内で破壊的変更を詳細に説明する方法を提供します。1文字の!マーカーとは異なり、フッターでは何が変わったか、コンシューマーがどのようにコードを更新すべきかの完全な説明が可能です。
形式
refactor(auth): switch from session cookies to JWT tokens
Migrate the authentication system from server-side sessions
to stateless JWT tokens. All API endpoints now expect a
Bearer token in the Authorization header.
BREAKING CHANGE: API endpoints no longer accept session cookies.
Clients must include a JWT token in the Authorization header.
The /api/session endpoint has been removed.
構造の分解
- 件名行:
refactor(auth): switch from session cookies to JWT tokens - 空行:件名と本文の間の必須区切り。
- 本文:変更の複数行の説明。
- 空行:本文とフッターの間の必須区切り。
- フッター:
BREAKING CHANGE: ...— 破壊的変更の説明。
フッタールール
- トークンは正確に
BREAKING CHANGE(スペース付き)またはBREAKING-CHANGE(ハイフン付き)でなければなりません。 :(コロンとスペース)の後に説明が続きます。- 説明は複数行にまたがることができます。
BREAKING CHANGEは大文字小文字を区別します —breaking changeは認識されません。
!との併用
!マーカーとフッターの両方を使用できます:
refactor(auth)!: switch from session cookies to JWT
BREAKING CHANGE: API endpoints no longer accept session cookies.
これにより最大限の可視性が得られます:短いログでは!が表示され、フッターが完全な説明を提供します。
複数の破壊的変更
単一のコミットが複数の破壊的変更を導入する場合、フッターにすべてをリストするか、複数のBREAKING CHANGE行を使用します。
ユースケース
破壊的変更に詳細な説明が必要な場合にBREAKING CHANGEフッターを使用します。APIコントラクトの変更、機能の削除、またはデータ形式の変更時に一般的です。フッターはコミット履歴内で直接、コンシューマーに明確な移行手順を提供します。