git-branch-naming

Git ブランチの命名規則

一貫したブランチ命名により、追跡しやすくなり、自動化が可能になり、リポジトリの履歴をたどりやすくなります。

このスキルを使用する場面

次の場合はこのスキルを使用します...	次の場合は別のものを使用します...
新しい機能／修正ブランチを作成するとき	PR ワークフローを管理するとき → git-branch-pr-workflow
チームのブランチ規則を設定するとき	変更をコミットするとき → git-commit-workflow
命名規則について話し合うとき	リベース／マージ戦略を検討するとき → git-branch-pr-workflow

ブランチ名の形式

{type}/{issue}-{short-description}

要素	形式	必須	例
type	小文字の接頭辞	はい	feat、fix
issue	# を付けない課題番号	課題がある場合	123
description	kebab-case、2～5 語	はい	user-authentication

例

# With issue number (preferred when issue exists)
feat/123-oauth-login
fix/456-null-pointer-crash
chore/789-update-dependencies
docs/101-api-reference

# Without issue number (when no issue exists)
feat/oauth-integration
fix/memory-leak-cleanup
chore/update-eslint-config
refactor/auth-service-split

ブランチの種類

種類	目的	Conventional Commit
feat/	新機能、機能追加	feat:
fix/	バグ修正	fix:
chore/	メンテナンス、依存関係、設定	chore:
docs/	ドキュメントのみ	docs:
refactor/	動作を変更しないコードの再構成	refactor:
test/	テストの追加／更新	test:
ci/	CI/CD パイプラインの変更	ci:
hotfix/	本番環境の緊急修正	fix:（緊急対応）
release/	リリースの準備	chore: または release:

ブランチの作成

標準的なワークフロー

# With issue number
git switch -c feat/123-user-authentication

# Without issue number
git switch -c fix/login-timeout-handling

# From specific base
git switch -c feat/456-payment-api main
git switch -c hotfix/security-patch production

検証パターン

作成前に、形式が正しいことを確認します。

# Branch name regex pattern
^(feat|fix|chore|docs|refactor|test|ci|hotfix|release)/([0-9]+-)?[a-z0-9]+(-[a-z0-9]+)*$

有効：

• feat/123-user-auth ✓
• fix/memory-leak ✓
• chore/update-deps ✓

無効：

• feature/user-auth ✗（feature ではなく feat を使用します）
• fix/UserAuth ✗（PascalCase ではなく kebab-case を使用します）
• my-branch ✗（種類の接頭辞がありません）
• feat/fix_bug ✗（アンダースコアではなくハイフンを使用します）

課題リンクのベストプラクティス

課題番号を含める場面

シナリオ	課題を含めるか	例
GitHub Issues で作業を追跡している	はい	feat/123-add-oauth
外部システム（Jira、Linear）で作業を追跡している	任意	feat/PROJ-456-oauth または feat/oauth
探索的な作業／スパイク作業	いいえ	spike/auth-approaches
課題のない軽微な修正	いいえ	fix/typo-readme
Dependabot／自動 PR	いいえ	chore/bump-lodash

外部チケットシステム

Jira、Linear、その他のシステムでは、チケット ID を使用します。

feat/PROJ-123-user-dashboard
fix/LINEAR-456-api-timeout
chore/JIRA-789-update-sdk

説明のガイドライン

良い説明

パターン	例	良い理由
アクション + 対象	add-oauth-login	何を行うのかが明確です
コンポーネント + 変更	auth-service-refactor	影響を受ける領域を特定できます
バグ + コンテキスト	null-pointer-user-save	問題の内容を説明しています

避けるべき例

アンチパターン	問題点	改善例
fix/bug	曖昧すぎます	fix/123-login-validation
feat/new-feature	意味がありません	feat/user-dashboard
feat/john-working-on-stuff	内容を説明していません	feat/456-payment-flow
fix/issue-123	冗長で、説明がありません	fix/123-timeout-error
feat/add-new-user-authentication-system-with-oauth	長すぎます	feat/oauth-authentication

長さのガイドライン

• 最小： 種類／課題番号の後に 2 語（feat/123-user-auth）
• 最大： 5 語、合計約 50 文字
• 最適： 3～4 語（feat/123-oauth-token-refresh）

特殊なブランチパターン

リリースブランチ

release/1.0.0
release/2.1.0-beta
release/v3.0.0-rc1

ホットフィックスブランチ

hotfix/security-vulnerability
hotfix/critical-data-loss
hotfix/production-crash-fix

長期ブランチ

数週間にわたる作業では、日付のサフィックスを検討してください。

feat/123-major-refactor-2026q1
epic/new-billing-system

チームの規則

ユーザー名を接頭辞に付けるブランチ（任意）

ブランチの所有者を明確にする必要がある大規模チーム向け：

# Pattern: {user}/{type}/{description}
alice/feat/123-oauth
bob/fix/456-memory-leak

# Or: {type}/{user}-{description}
feat/alice-oauth-integration
fix/bob-memory-leak

保護対象ブランチのパターン

次のブランチにブランチ保護を設定します。

main
master
develop
release/*
hotfix/*

自動化との連携

ブランチ名 → コミットのスコープ

ブランチの種類は、コミットメッセージのスコープを決める際の参考になります。

ブランチ	推奨されるコミット
feat/123-auth	feat(auth): ...
fix/456-api	fix(api): ...
docs/readme	docs: ...

CI/CD のトリガー

CI パイプラインのトリガーによく使われるパターン：

# GitHub Actions example
on:
  push:
    branches:
      - 'feat/**'
      - 'fix/**'
      - 'hotfix/**'
  pull_request:
    branches:
      - main

クイックリファレンス

ブランチ作成チェックリスト

• 有効な種類のプレフィックス（feat/、fix/ など）で始まっている
• 課題番号が含まれている（追跡対象の作業の場合）
• 説明がケバブケースになっている
• 説明が 2～5 語になっている
• 全体の長さが 50 文字未満である
• アンダースコア、スペース、大文字が含まれていない

コマンドリファレンス

操作	コマンド
ブランチを作成	git switch -c feat/123-description
種類別に一覧表示	git branch --list 'feat/*'
ローカルブランチを削除	git branch -d feat/123-description
リモートブランチを削除	git push origin --delete feat/123-description
名前を変更	git branch -m old-name new-name

種類選択のフローチャート

Is it a bug fix? → fix/
Is it a new capability? → feat/
Is it documentation? → docs/
Is it maintenance/deps? → chore/
Is it restructuring code? → refactor/
Is it adding tests? → test/
Is it CI/CD changes? → ci/
Is it an emergency? → hotfix/