はじめに
Gitを使った開発で、地味に時間を取られるのが次のような場面です。
・ブランチ名をどう付けるか迷う
・コミットメッセージが毎回ブレる
・見た目変更やパフォーマンス改善の扱いに悩む
本記事では、
英語ベース + 日本語用途補足 を採用し、
さらに コミットテンプレート前提 で運用できるブランチ名・コミットメッセージの命名規則を「自分用メモ」として整理します。
※ 厳密な正解ではなく、一貫性を保つためのルールです。
命名規則の前提
・完璧さより 一貫性
・ブランチ名・コミット名は 英語で統一
・() 内に 日本語用途名を入れて分かりやすく
・「何をしたか」より 変更の性質・目的が分かること
ブランチ名の命名規則
基本フォーマット
<type>(日本語用途)/<content>
命名ルール
・kebab-case（-）で統一
・content は名詞・名詞句
・見ただけで変更内容が想像できる粒度
type 一覧（最終版）
| type | 日本語用途 |
|---|---|
| feature | 新機能 |
| fix | バグ修正 |
| style | UI変更・見た目 |
| refactor | リファクタ |
| chore | 環境整備・雑務 |
| docs | ドキュメント |
| test | テスト |
| perf | パフォーマンス |
| security | セキュリティ |
| ci | CI/CD |
| data | DB・データ |
| a11yvアクセシビリティ | |
| spike | 調査・検証 |
| ai | AI連携 |
ブランチ名の例
feature(新機能)/user-registration
fix(バグ修正)/login-validation
style(UI変更)/post-card-layout
perf(パフォーマンス)/n-plus-one-fix
security(セキュリティ)/csrf-token
ci(CI/CD)/add-github-actions
data(DB)/add-user-index
a11y(アクセシビリティ)/aria-labels
spike(調査)/search-library
ai(AI連携)/prompt-optimization
コミットメッセージの命名規則
基本フォーマット
<type>(日本語用途): <summary>
summary のルール
・現在形の動詞を使う
・1コミット = 1変更
・50文字以内を目安
コミットメッセージ例
feat(新機能): add user registration
fix(バグ修正): validate login parameters
style(UI変更): adjust post card spacing
perf(パフォーマンス): add index to users table
security(セキュリティ): restrict admin access
ci(CI/CD): add rspec workflow
data(DB): update schema for posts
a11y(アクセシビリティ): add aria-label to buttons
spike(調査): test full-text search options
ai(AI連携): optimize prompt for cost reduction
chore / refactor / style の違い
| type | 主な対象 | 目的 | 挙動 |
|---|---|---|---|
| style | 見た目・UI | 視認性・体験改善 | 変わらない |
| refactor | アプリコード | 可読性・保守性改善 | 変わらない |
| chore | 環境・設定 | 開発環境整備 | 変わらない（ことが多い） |
判断に迷ったら、
「ユーザーが直接触る変化か？」
→ YES：style
→ NO：refactor / chore
コミットメッセージテンプレート運用
Step1. リポジトリ直下にテンプレートファイルを作成する
まず、対象のアプリのルートディレクトリに移動します。
cd your-app-name
テンプレートファイルを作成します
touch .gitmessage
Step2. テンプレートの中身を記述する
エディタで開いて、内容を記述します。
code .gitmessage
<type>(日本語用途): <summary>
# type:
# feature(新機能)
# fix(バグ修正)
# style(UI変更)
# refactor(リファクタ)
# chore(環境整備)
# docs(ドキュメント)
# test(テスト)
# perf(パフォーマンス)
# security(セキュリティ)
# ci(CI/CD)
# data(DB)
# a11y(アクセシビリティ)
# spike(調査)
# ai(AI連携)
#
# rules:
# - use present tense
# - one commit, one purpose
# - keep summary under 50 chars
Step3. Gitに「このリポジトリ用」として登録する
git config commit.template .gitmessage
※ --global は付けません。
これでこのリポジトリ限定でテンプレートが有効になります。
Step4. 動作確認する
git add .
git commit
エディタが開き、
.gitmessage の内容が自動表示されていれば成功です。
Step5. コミットメッセージを入力して保存する
1行目だけコメント（#）を消して、1行目を記述します。
＊こんな感じ
保存してエディタを閉じると、そのままコミットが作成されます。
＊VSCodeだと Cmd + S で保存して COMMIT_EDITMSG タブを 閉じるとコミットが確定します。
以下で確認してコミットメッセージの確認ができればOK
git log --oneline -1
git commit と git commit -m の違い
git commit
git commit
・エディタが開く
・テンプレートが 自動で表示される
・コメントを消して入力 → 保存でコミット
命名を安定させたい場合はこちら。
git commit -m
git commit -m "style(UI変更): adjust post card spacing"
・エディタは開かない
・テンプレートは使われない
・慣れてきた後の省略用
注意点
・テンプレートは 表示されるだけ
・コメント行のみで保存すると
空メッセージ扱いでコミットされない
まとめ
・英語 + 日本語用途補足で可読性が向上
・UI・非機能要件も type として明示できる
・テンプレート運用で命名の迷いをほぼゼロにできる
「これは何系の変更か？」 を
名前にそのまま残すことで、git log が最高の開発ログになると思うので、意識して使っていきます！
ぺ