mcpField
G
git

git

github.com/epicenterhq開発4.8k82 回インストール2 週間前に更新
リポジトリ

git について

Conventional Commits に沿った Git コミットメッセージの作成とコミット構成を扱うスキルです。一貫性があり、レビューしやすい原子的な変更を目指し、プルリクエスト作業は別のスキルに案内します。

主な機能

  1. 01Conventional Commits の種別と形式
  2. 02任意の具体的なスコープの指針
  3. 03件名の表現と長さの規則
  4. 04破壊的変更の表記とバージョン更新
  5. 05本文に理由を記す原子的なコミット

活用シーン

  1. 01修正や機能追加のコミット作成
  2. 02局所的な変更のスコープ選択
  3. 03破壊的変更とバージョンへの影響の記録

インストール

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

$npx skills add https://github.com/epicenterhq/epicenter --skill git

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

詳細

Git コミットのガイドライン

関連スキル: 各コミットをレビューおよび監査しやすくする方法や、複数ファイルにまたがる変更を依存関係順の段階に分ける方法については、standalone-commits を参照してください。PR のタイトル、説明、変更履歴の項目、課題への参照、マージに関するガイダンスについては、pull-request を参照してください。

PR の境界

PR のタイトル、PR の本文、変更履歴の項目、課題へのリンク、ユーザー名の確認、CODEOWNERS に関する注記、マージ戦略については、pull-request を参照してください。

参考資料

このスキルのルールは本文中に記載しています。PR 作業には、pull-request を使用してください。

Conventional Commits の形式

<type>[optional scope]: <description>

[optional body]

[optional footer(s)]
コミットの種類
  • feat: 新機能（セマンティックバージョニングの MINOR に対応）
  • fix: バグ修正（セマンティックバージョニングの PATCH に対応）
  • docs: ドキュメントのみの変更
  • refactor: バグ修正や機能追加を伴わないコード変更
  • perf: パフォーマンスの改善
  • test: テストの追加または変更
  • chore: メンテナンスタスク、依存関係の更新など
  • style: コードスタイルの変更（フォーマット、セミコロンの不足など）
  • build: ビルドシステムまたは依存関係の変更
  • ci: CI 設定ファイルおよびスクリプトの変更
スコープのガイドライン
  • スコープは任意です: 明確になる場合にのみ追加してください
  • 小文字を使い、種類の後に括弧で囲んで記述します: feat(transcription):
  • 一般的な用語より、具体的なコンポーネント名やモジュール名を優先してください
  • 現在の使い方は適切です。コンポーネント名（EditRecordingDialog）、機能領域（transcription、sound）を使います
  • 本当に適切な場合を除き、ui や backend のような汎用的すぎるスコープは避けてください
スコープを使う場合
  • 変更が特定のコンポーネントやモジュールに限定されている場合
  • 類似した変更を区別するのに役立つ場合
  • 領域が明確に分かれた大規模なコードベースで作業する場合
スコープを使わない場合
  • 変更が複数の領域に同程度の影響を与える場合
  • 種類だけで十分に内容を説明できる場合
  • 小さく、明白な変更の場合
説明のルール
  • コロンとスペースの直後は小文字で始めます
  • 命令形を使います（「added」や「adds」ではなく「add」）
  • 文末にピリオドを付けません
  • 1 行目は 50～72 文字以内に収めます
破壊的変更とバージョンの更新

モノレポでは、メジャーバージョン 8 を固定した統一バージョン方式（8.Y.Z）を使用します。

  • パッチ（デフォルト）: マージされた PR ごとに Z が増加します（例: 8.0.1 → 8.0.2）
  • マイナー: 種類またはスコープの後に ! を追加します: feat(api)!: change endpoint structure。Y が増加し、Z はリセットされます
  • メジャー: 手動でのみ更新します。「必要になれば」という場合のみに限ります。メジャー更新を期待して ! を使わないでください

! を使う場合は、詳細をコミットフッターに BREAKING CHANGE: として記載してください。

スタイルに沿った例:
  • feat(transcription): add model selection for OpenAI providers
  • fix(sound): resolve audio import paths in assets module
  • refactor(EditRecordingDialog): implement working copy pattern
  • docs(README): clarify cost comparison section
  • chore: update dependencies to latest versions
  • fix!: change default transcription API endpoint

コミットメッセージのベストプラクティス

「何を」より「なぜ」が重要

コミットメッセージの件名行では、何が変更されたかを説明します。コミット本文では、なぜ変更したかを説明します。

良いコミット（動機を説明）:

fix(auth): prevent session timeout during file upload

Users were getting logged out mid-upload on large files because the
session refresh only triggered on navigation, not background activity.

悪いコミット（何をしたかだけを説明）:

fix(auth): add keepalive call to upload handler

最初のコミットは、そのコードが存在する理由を後の開発者に伝えます。2 つ目のコミットでは、目的を理解するためにコードを調べる必要があります。

その他のベストプラクティス
  • Claude Code や opencode のウォーターマークや帰属表示は絶対に含めないでください
  • 各コミットは単一の不可分な変更を表すものにしてください
  • 将来の開発者（自分自身を含む）のためにコミットを書いてください
  • 何をしたかの説明に 1 行以上必要な場合は、コミットを分割することを検討してください

含めてはならないもの：

  • Generated with [Claude Code](https://claude.ai/code)
  • Co-Authored-By: Claude <[email protected]>
  • AI による支援への言及
  • Generated with [opencode](https://opencode.ai)
  • Co-Authored-By: opencode <[email protected]>
  • ツールのクレジット表記やウォーターマーク

コメント

Markdown 対応