💡

Conventional Commitsフォーマット

に公開
Git
tech

はじめに

本記事は、ChatGPTから得た知見をもとに、Conventional Commitsのフォーマットについて詳述しています。コミットメッセージの一貫性と可読性を向上させるために、Conventional Commitsの採用を強く推奨します。これは、プロジェクトの透明性と協働効率を大幅に向上させる手法です。

Conventional Commitsフォーマット

Conventional Commitsは、以下の形式に従ったコミットメッセージのスタイルガイドです。

基本構造

コミットメッセージは、以下のような形式で書かれます：

<type>[optional scope]: <description>

[optional body]

[optional footer(s)]

各部分の説明

  1. type: コミットの種類を示します。主な種類は以下の通りです：

    • feat: 新しい機能の追加
    • fix: バグ修正
    • docs: ドキュメントの変更（コード変更なし）
    • style: フォーマットやスペース、セミコロンの追加など、コードの意味に影響を与えない変更
    • refactor: リファクタリングのためのコード変更（バグ修正や新機能の追加なし）
    • perf: パフォーマンス改善のための変更
    • test: テストコードの追加や修正
    • chore: ビルドプロセスや補助ツール、ライブラリの変更など

  2. scope（任意）: 変更の影響範囲を示します。これはモジュールや機能の名前を指定することで、変更の対象を明確にします。例：feat(auth): add login feature

  3. description: 簡潔で具体的な変更内容の説明を記述します。50文字以内が推奨されます。

  4. body（任意）: 変更の詳細を記述します。なぜこの変更が必要か、どのように変更したかなどの情報を含めます。

  5. footer(s)（任意）: 重要な追加情報を記述します。例えば、破壊的変更（breaking change）の情報や、特定のイシューに関連するコミットの場合にそのイシュー番号を記載します。例：

    • 破壊的変更の場合：
      BREAKING CHANGE: description of the change
    • イシュー番号を含む場合：
      Closes #123

コミットメッセージの例

  • 新機能追加:

    feat(auth): add login feature

  • バグ修正:

    fix(layout): correct header alignment

  • ドキュメント変更:

    docs(readme): update installation instructions

  • スタイル変更:

    style: format code with Prettier

  • リファクタリング:

    refactor: simplify user authentication logic

  • パフォーマンス改善:

    perf: improve database query performance

  • テスト追加:

    test: add unit tests for user model

  • 雑用（chore）:

    chore: update dependencies

まとめ

Conventional Commits形式を採用することで、コミット履歴が一貫性を持ち、後から変更履歴を追いやすくなります。これにより、プロジェクトのメンテナンス性が向上し、チーム全体の効率が高まります。

Discussion