🚀

コミットメッセージの規約

に公開
Git
コミットメッセージ
idea

コミットメッセージの規約

Conventional Commits

コミットメッセージの記述方法は、チームによって異なりますが、特に広く使われているのは Conventional Commits という規約に基づくスタイルです。

Conventional Commits では、以下のフォーマットでコメントを記述します。

<type>(<scope>): <description>

Type

Conventional Commits の type 部分では、以下のラベルがよく使用されます。

type 意味 例
feat: 新機能追加 feat: Add login button to header
fix: バグ修正 fix: Resolve crash on screen rotation
refactor: リファクタリング（振る舞いの変更なし） refactor: Simplify ViewModel logic
style: コードのフォーマットの変更（リファクタを除く） style: Format code with ktlint
docs: ドキュメントの修正 docs: Update README with usage info
test: テストコードの追加・変更 test: Add unit test for UserRepository
chore: その他雑務（ビルド設定、CI構成など） chore: Update Gradle wrapper version
perf: パフォーマンス改善 perf: Optimize RecyclerView scrolling
build: ビルドシステムや依存関係の変更 build: Upgrade to Compose 1.6.0
ci: CI/CD 関連の設定変更 ci: Add GitHub Actions workflow
revert: 変更の取り消し revert: Revert "feat: Add settings screen"

注意 : UI (画面上) の見た目の変更は、 style: ではなく、 feat: や fix: を使用してください。

これらのラベルは、 Conventional Commits で推奨されているものであるため、チーム内で独自に定義するよりは、これらのラベルを使用することがお勧めです。

使い方のポイント

  • コロンの後には 半角スペース を入れる（例： feat: ）
  • コミットメッセージの一行目は 簡潔に要点だけ（ 50 文字以内が望ましい）
  • 複雑な変更は、 2 行目を空けて詳細を本文に書く
  • prefix は、一つのコミットに対して一つまで
    • ツールで自動的にログ解析やリリースノート生成を行うため
    • 「やることを 1 つに絞る」というコミット設計の原則とも一致する
    • 一つのコミットに複数の目的を含む場合は、コミットを分割できないか検討する
    • どうしても 1 つにしたいときは、主目的を prefix に記述して、他の目的は本文に記載する

なぜ接頭辞を使うのか？

  • チーム内で「何のための変更か」がすぐにわかる
  • Gitログが綺麗に整理される
  • リリースノート自動生成ツール（例：semantic-release）と連携できる

Scope

Conventional Commits の scope は、 type で指定した修正範囲をさらに絞り込むのに使用されます。

scope は、どの type の場合でも付与することが可能です。また、オプションであるため、何も指定しないことも可能です。

scope は、規約で定められたラベルはなく、チーム内で任意のラベルを定義する必要がありますが、一般的には、以下のものがよく使用されます。

type scope コミット例 意味
feat ui feat(ui): add dark mode toggle UIに新機能を追加
fix api fix(api): handle null response in login endpoint API部分のバグ修正
refactor auth refactor(auth): simplify token validation 認証ロジックのリファクタ
chore deps chore(deps): bump kotlin from 1.9.20 to 1.9.22 依存関係の更新。 dependencies の略。
chore release chore(release): prepare v1.2.0 リリース準備
ci github ci(github): fix build matrix CI 設定修正
test api test(api): add missing tests for auth API部分のテスト追加

scope には、複数のスコープを指定することも可能です。例えば、以下のように「開発環境」を意味する dev と、依存関係の変更を意味する deps ( dependencies の略) を併用することが可能です。

chore(dev-deps): update junit version

Discussion