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.

構造の分解

  1. 件名行refactor(auth): switch from session cookies to JWT tokens
  2. 空行:件名と本文の間の必須区切り。
  3. 本文:変更の複数行の説明。
  4. 空行:本文とフッターの間の必須区切り。
  5. フッター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コントラクトの変更、機能の削除、またはデータ形式の変更時に一般的です。フッターはコミット履歴内で直接、コンシューマーに明確な移行手順を提供します。

試してみる — Conventional Commits Linter

フルツールを開く