コミットメッセージ規範の重要性

Git のコミット情報は、単なるコードの変更記録ではなく、プロジェクトの歴史を語るドキュメントです。不明確なメッセージ（例：`update`、`fix` など）は、将来的なバグ修正や機能追加において、変更の意図を追跡することを困難にさせます。適切な規範を導入することで、以下のようなメリットが得られます。

• 可読性の向上： 数ヶ月後にコードを見直した際、変更の背景を理解できる。
• CHANGELOG の自動生成： 構造化された情報からリリースノートを作成可能。
• セマンティックバージョニング： 変更の種類に基づきバージョン番号を自動的に調整。
• レビュー効率化： コードベースの変更範囲と目的を即座に把握できる。

コア規格：Angular スタイリングの詳細

現在、業界で最も広く採用されている形式はAngular チームによって策定されたフォーマットです。基本的な構造は「ヘッダー」「ボディ」「フッター」から成り立ちます。

<タイプ>(スコープ): <要約文>

<任意の本体記述>

<任意の参照フッター>

実際の運用では、最初の行である「ヘッダー」の構成要素が最も重要です。以下のテーブルに主要なトピック类型とその役割を示します。

実用的なコーディングシナリオ

理論を踏まえた具体的なコミット入力例を紹介します。

ケースA：新しいモジュールの導入

git commit -m "feat(payment): Stripe サブスクリプション機能を統合"

ケースB：本番環境の critical バグ対応

git commit -m "fix(inventory): 在庫数を超過しても予約が成立していた事象を解消"

ケースC：詳細な変更理由が必要な場合

簡易コマンドではなくエディタを起動し、詳細を記述するのが望ましいパターンです。

# エディタでの入力例
refactor(service): 認証ロジックの依存性をInjection制御へ移行

既存のSingleton パターンを変更し、モックテストを組み込みやすい構造へ再設計。
これによりユニットテストのカバレッジが向上する。

See: JIRA-8821

チームルール遵守のための自動化構成

マニュアルだけでは徹底が難しいため、CLI ツールによる強制力を活用するのが一般的です。

1. 対話型入力支援：Commitizen

ターミナル上で選択肢を選ばせることで、正しい形式を導出します。

npm i -D commitizen cz-conventional-changelog

package.json 内の設定項目：

{
  "scripts": {
    "cm": "git-cz"
  },
  "config": {
    "commitizen": {
      "path": "cz-conventional-changelog"
    }
  }
}

この設定後、通常の git commit ではなく npm run cm を実行することでウィザードが起動します。

2. コミット情報の検証：Commitlint + Husky

手動で git commit -m を行った場合に不正な形式を弾くためのバリデーションシステムです。

インストール処理：

npm i -D @commitlint/cli @commitlint/config-conventional husky

コンフィグファイル作成 (commitlint.config.mjs)：

import conventional from '@commitlint/config-conventional';

export default {
  extends: ['conventional'],
  // ここで独自ルールの上書きが可能
  rules: {
    'subject-case': [2, 'never', ['sentence-case', 'start-case']]
  }
};

Husky の設定：

npx husky init
echo "npx --no-install commitlint --edit \$1" > .husky/commit-msg

これで、要件を満たさないコミットメッセージがローカルリポジトリに反映されることを防げます。

3. リリースログの生成：Standard Version

規定されたコミット履歴を元に、自動でリリースノートを書き起こす仕組みです。

npm i -D standard-version

リリーススクリプトの追加：

{
  "scripts": {
    "release": "standard-version"
  }
}

npm run release を実行すると、package.json のバージョン更新、CHANGELOG.md の更新、そして Git タグの作成が一括で行われます。

現場での運用指針

以下の原則を守ることで、長期的にメンテナンスしやすいリポジトリを維持できます。

• 原子性の確保： 一つのコミットでは一つの論理的な変更のみを行うこと。「バグ修正」と「機能追加」は別々のコミットに分ける。
• 言語の一貫性： チーム内で使用する言語を統一する。グローバルチームであれば英語、国内プロジェクトであれば分かりやすい日本語の使用が推奨される。
• ツールによるガードレール： Commitizen で入力の手間を減らし、Commitlint でエラーを検知する二重の体制を敷くことが、技術的負債を防ぐ鍵となります。
• スコープの明確化： どのモジュールやコンポーネントを変更するかを (scope) に明記することで、影響範囲を可視化する。