💹

Conventional Commit の TYPE 選択フロー

に公開
Git
conventionalcommit
tech

tl;dr

選択フロー

基本的な考え方

  • 上から順に確認し、最初に当てはまる TYPE を選択
  • チームで合意したら独自の TYPE を追加するといい

思想:

  • 関係するファイル（のコミット）を TYPE で集約することで、履歴参照を容易にする
  • リリース自動化時の機械的判定を容易にする
  • 安易に fix/feat/chore を選択しないようにする

revert

使用条件: 特定のコミットの変更を取り消す場合

  • git revert の結果をそのままコミットする（余計な変更を追加しない）
  • 基本的に自動生成されるため、手動での使用頻度は低い
  • 高頻度で使用する場合は開発フローの見直しを検討すること

build

使用条件: ビルドプロセスに関係する変更

対象ファイル:

  • Make、Taskfile 等のビルドタスクファイル
  • ビルド用のシェルスクリプト
  • ビルドプロセスから参照される設定ファイル
  • 注意: ワークフローファイル（.github/workflows/等）は含めない → ci を使用

test

使用条件: テスト用のファイルの変更

重要な注意点:

  • 「作業的な意味でのテスト」としての使用は 禁止
  • ユニットテストコードの扱いは要検討（本体コードとセットであるべき）

判断基準:

  • ユニットテスト以外のテストコード（E2E、統合テスト等）
  • テスト関連ファイルを集約することで参照性が向上する場合
  • コード本体とユニットテストを別コミットで PR を出したい場合など

ci

使用条件: CI/CD に関係する変更

対象ファイル:

  • GitHub Actions 等のワークフローファイル
  • CI/CD 用の設定ファイル
  • デプロイメント関連スクリプト
  • .github/ ディレクトリ配下はすべて ci とすると判断が楽

style

使用条件: フォーマッター・リンターによる機械的な変更

対象ファイル:

  • Prettier、ESLint 等の自動修正結果
  • 変更されたフォーマット設定の適用
  • 古いファイルへの現行設定の適用
  • 基本的に機械的な変更のみに限定する
  • 後で参照する価値が低い（参照不要と判断できるようにすると後々楽）

refactor

使用条件: 外部仕様を変えない内部構造の改善

定義: ソフトウェアの外部から見た動作を変えずに、コードの内部構造を改善する作業

対象例:

  • プライベート変数の変数名変更
  • コードフォーマット（機械的でない改行・スペース調整）
  • Terraform のリソース名変更（movedブロック使用で plan 差分なし）

注意:

  • この変更で問題を発生させてはならない。参照不要になるよう使用を限定することを推奨
  • プライベートメソッドのシグネチャ変更（影響範囲が大きい）
  • 動作に影響する可能性がある変更

perf

使用条件: パフォーマンス改善に特化した変更

対象例:

  • 明らかに低速なアルゴリズムの高速化
  • メモリ使用量の最適化
  • 計算量の改善

注意:

  • 日常的にパフォーマンス修正が必要な状況は設計を見直すべき
  • 早期リターンの追加等は慎重に判断（バグの温床になる可能性）

docs

使用条件: ドキュメント（コメント含む）の変更

対象:

  • README、API ドキュメント等の更新
  • コメントの修正・追加
  • タイポ（誤字・脱字）の修正
  • 人が読むもので、コードの動作に影響しない変更

fix

使用条件: バグの修正

対象:

  • 明確なバグフィックス
  • 仕様変更への対応（要チーム判断）

注意:

  • 「期待している状態への変更」は feat との境界が曖昧
  • 設定値の変更等、仕様変更はバグではないことに留意
  • 可能な限りバグフィックスのみに限定することを推奨

feat

使用条件: 新機能・仕様の追加

対象:

  • 新しいメソッド・関数の追加
  • 新しいファイル・モジュールの追加
  • 既存機能の拡張
  • 機能の削除（仕様変更の一種）

例:

  • Terraform でのリソース追加
  • API エンドポイントの追加
  • 新しい設定オプションの追加

chore

使用条件: 上記のいずれにも当てはまらない変更

使用例:

  • 複数の軽微な修正が混在（TYPO 修正 + コメント修正 + フォーマット調整等）
  • 依存関係の更新
  • 設定ファイルの軽微な調整
  • 基本的に後で参照不要な内容になるべき

注意:

  • できるだけ使用を避け、適切な TYPE に分類する
  • 必要なら新しい TYPE を追加することを検討する

まとめ

優先順位

  1. リリース自動化: 機械的な TYPE 判定を容易にする
  2. 履歴参照性: 読み飛ばしやすく、検索しやすい履歴を作る
  3. コミット品質向上: update xxx file や add xxx のような無意味なタイトルを削減

カスタマイズのポイント

  • 基準は各自またはチームで相談して決定
  • プロジェクトに応じて必要な TYPE を追加
  • リポジトリの性質に合わせた調整が重要

おまけ

scop について

スコープは必須ではないが、適切に使用することで履歴の可読性が向上する。

推奨ルール:

  • ディレクトリ名や機能名で統一的に分類
  • チーム内で共通認識を持つ（勝手な分類は後でメンテナンスが困難）
  • 例: feat(auth): ログイン機能を追加, fix(api): ユーザー取得エラーを修正

日本語タイトルについて

言語選択の考え方:

  • 日本語チームなら日本語を使用していいよね派
  • 簡潔に表現できる場合は英語も有効（例: fix: formula in xxx()）

良いタイトルの書き方:

  • ❌ update README → ❌ 何を更新したか不明
  • ✅ docs: APIドキュメントにSSOによる認証方法を追加
  • ❌ ◯◯を修正した → ❌ 曖昧
  • ✅ fix: 変数名 userId を user_id に変更
  • ✅ fix: チケット#999対応 - 項目AをBに変更
  • ❌ fix: 最大値変更 → ✅ fix: max_xxx from 1 to 2 や fix: max_xxx を 2 に変更

ポイント: 「やったこと」ではなく「何が起きるのか」を説明する

本文について

書くべき内容:

  • 変更した理由（何をしたかはコードを見る、どうしたいのかを書く）
  • 背景となる課題や要求
  • 関連するチケット番号や Issue 番号
  • 関連する技術のドキュメントへのリンク等
  • 将来の参考になる技術的な判断根拠
  • 本文から 1 ホップでレビューに必要な情報にアクセスできることを目指す

避けるべき内容:

  • テンプレートの不要部分をそのまま残す
  • 「軽微な修正」等の曖昧な説明
  • 本文を空にする

目標: 半年後、数年後の自分が見返した時に状況を正しく理解できる内容にする

追加の TYPE

  • ライブラリ等のバージョンアップは bump がよく使われるが、対象のファイル用の TYPE がすでにあることに留意する（build: bump libxxx や ci: bump lint toolなどで十分では？）
  • terraform の drift 対応
  • オートスケーリングのリミット調整
  • デバッグ用のログの追加
  • 分類に困るケースはいくらでもあるので、ADR を書くか、pre-commit 等のツールで共有する

Discussion