mcpField
C
conventional-commit

conventional-commit

github.com/marcelorodrigo開発19955 回インストール8 週間前に更新
リポジトリ

conventional-commit について

開発者やコーディングエージェント向けに、Git のコミットメッセージとブランチ準備を定めるスキルです。Conventional Commits の種類に加え、件名や本文、破壊的変更のルールを扱います。

主な機能

  1. 01種類別のコミット形式
  2. 02ブランチ命名の指針
  3. 03件名と本文のルール
  4. 04破壊的変更と取り消しの形式
  5. 05単一変更のコミット原則

活用シーン

  1. 01コミット前のフィーチャーブランチ準備
  2. 02修正・機能・リファクタリングの記述
  3. 03API の破壊的変更の説明
  4. 04過去のコミットの取り消し

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/marcelorodrigo/agent-skills --skill conventional-commit

インストール後、Claude Code で/conventional-commitを入力して読み込まれたか確認します。

詳細

Conventional Commit メッセージ

コミットを作成する際は、次の規約に従ってください。

前提条件

コミットする前に、main ブランチではなくフィーチャーブランチで作業していることを確認してください。

# Check current branch
git branch --show-current

main または master にいる場合は、まず新しいブランチを作成してください。

# Create and switch to a new branch
git checkout -b <type>/<short-description>

ブランチ名は <type>/<short-description> のパターンに従い、type はコミットタイプと一致させてください（例：feat/add-user-auth、fix/null-pointer-error、refactor/extract-validation）。

形式

<type>(<scope>): <subject>

<body>

<footer>

ヘッダーは必須です。スコープは任意です。すべての行を100文字未満にしてください。

コミットタイプ

タイプ目的
buildビルドシステムまたは CI の変更
chore定常的なメンテナンス作業
ci継続的インテグレーションの設定
deps依存関係の更新
docsドキュメントの変更
feat新機能
fixバグ修正
perfパフォーマンスの改善
refactorコードのリファクタリング（動作の変更なし）
revert以前のコミットの取り消し
styleコードのスタイルとフォーマット
testテストの追加、更新、改善

件名のルール

  • 命令形の現在形を使ってください。「added feature」ではなく「add feature」とします
  • 先頭の文字を大文字にしないでください
  • 末尾にピリオドを付けないでください
  • 最大70文字です

本文のガイドライン

  • 方法ではなく、何を、なぜ行うのかを説明してください
  • 命令形の現在形を使ってください
  • 変更の動機を記載してください
  • 関連する場合は、以前の動作との違いを説明してください

Conventional Commits

コミットには、ライブラリの利用者に意図を伝えるため、次の構造要素が含まれます。

  • fix：fix タイプのコミットは、コードベースのバグを修正します（Semantic Versioning の PATCH に対応します）。
  • feat：feat タイプのコミットは、コードベースに新機能を導入します（Semantic Versioning の MINOR に対応します）。
  • BREAKING CHANGE：BREAKING CHANGE: フッターを含むコミット、またはタイプ／スコープの後に ! を付けたコミットは、API に破壊的変更を導入します（Semantic Versioning の MAJOR に対応します）。BREAKING CHANGE は、どのタイプのコミットにも含めることができます。
  • fix: と feat: 以外のタイプも使用できます。たとえば、@commitlint/config-conventional（Angular の規約に基づく）では、build:、chore:、ci:、docs:、style:、refactor:、perf:、test: などが推奨されています。
  • BREAKING CHANGE: 以外のフッターも指定でき、git trailer 形式と同様の規約に従います。

例

簡単な修正
fix(api): handle null response in user endpoint

The user API could return null for deleted accounts, causing a crash
in the dashboard. Add null check before accessing user properties.
スコープ付きの機能
feat(alerts): add Slack thread replies for alert updates

When an alert is updated or resolved, post a reply to the original
Slack thread instead of creating a new message. This keeps related
notifications grouped together.
リファクタリング
refactor: extract common validation logic to shared module

Move duplicate validation code from three endpoints into a shared
validator class. No behavior change.
破壊的変更
feat(api)!: remove deprecated v1 endpoints

Remove all v1 API endpoints that were deprecated in version 23.1.
Clients should migrate to v2 endpoints.

BREAKING CHANGE: v1 endpoints no longer available

Revert の形式

revert: feat(api): add new endpoint

This reverts commit abc123def456.

Reason: Caused performance regression in production.

原則

  • 各コミットは、単独で安定した変更にしてください
  • コミットは個別にレビューできるようにしてください
  • 各コミットの後、リポジトリが正常に動作する状態を保ってください

参考資料

コメント

Markdown 対応