- はじめに
- 結論：おすすめの基本形式
- よく使われるブランチ名
- 「main」：安定したコードを管理するブランチ
- 「develop」：次回リリースの変更を統合するブランチ
- 「feature/」「feat/」：新しい機能を追加する
- 「fix/」「bugfix/」：通常のバグを修正する
- 「hotfix/」：本番環境の問題を緊急修正する
- 「release/」：リリース前の最終調整を行う
- 「chore/」：開発環境や依存関係を保守する
- 「docs/」：ドキュメントを変更する
- 「refactor/」：動作を変えずに内部構造を改善する
- 「test/」：テストコードを追加・修正する
- 「ci/」「build/」：CI/CDやビルド設定を変更する
- 「perf/」：パフォーマンスを改善する
- 「style/」：コードの見た目を整える
- 「revert/」：過去の変更を取り消す
- 「spike/」「experiment/」：技術調査や実験を行う
- ブランチ命名時の注意点
- おまけ：今のブランチ名形式が慣習となった背景
- 最後に
はじめに
さて今回は、GitHubでよく使われるブランチ命名の慣習についてまとめたいと思います。
GitやGitHubを使った開発では、機能追加やバグ修正を行う際にブランチを作成します。例えば以下のようなブランチです。
feature/add-login
fix/handle-null-response
hotfix/fix-login-errorこの「feature」や「fix」などは当たり前のように用いられていますが、初めて見ると何これ・・・となりませんか？？私はなりました。
実はこれ、ブランチで行う作業の種類を表す接頭辞として慣習的に用いられている名称らしいです。接頭辞を見れば、そのブランチが機能追加用なのか、通常のバグ修正用なのか、緊急対応用なのかを判断しやすくなるという意図です。
ただ、そんな慣習知らないですよね。
今回はそんな慣習をまとめてみましたので、私と同じような初学者の参考になれば嬉しいです！
それでは見ていきましょう～
結論：おすすめの基本形式
多くのチームで利用しやすいブランチ名の基本形式は、以下の通りです。
<作業の種類>/<チケット番号>-<変更内容>具体例をいくつか見るとイメージつきやすいかもしれません。
GitHub Issueの123番に対応してログイン機能を追加する場合：feature/GH-123-add-login
Jiraのプロジェクトキーが"APP"で、456番のバグを修正する場合：fix/APP-456-handle-null-responseまた、チケット管理ツールなどを使用していない場合は以下のようにチケット番号を省略した形式で命名することもあります。
feature/add-login
fix/handle-null-responseこの形式にするメリットは以下のようなことが考えられます。
- ブランチで行う作業の種類が分かる
- 対応するIssueやチケットを探しやすい
- 変更内容をブランチ一覧から推測できる
- Pull RequestやCI/CDのルールと連携しやすい
もちろん必ずこの形式にしなければならないというものではありません。GitHubでこのように命名しないと使えないというわけでもないです。
冒頭もお伝えしましたが、あくまでも「慣習」ということは覚えておきましょう。こうしておくと分かりやすいから開発者はよくこうしているよというだけです。各プロジェクト毎にルールが定めれているようであれば、そちらに従いましょう。
よく使われるブランチ名
よく使われるブランチ名を紹介します。
全て採用する必要はありません。接頭辞を増やし過ぎると、逆にどれを選べばよいか分かりにくくなるためです。プロジェクトで実際に区別する必要があるものだけを採用しましょう。
| 接頭辞・ブランチ名 | 主な用途 | 例 |
|---|---|---|
| main | 安定版・本番リリース可能なコード | main |
| develop | 次回リリースに向けた変更の統合 | develop |
| feature/ feat/ | 新機能の追加 featureの短縮形としてfeatが用いられることもある | feature/add-login feat/add-login |
| fix/ bugfix/ | 通常のバグ修正 | fix/handle-null-response bugfix/handle-null-response |
| release/ | リリース前の最終調整 | release/2.4.0 |
| chore/ | 依存関係更新などの保守作業 | chore/update-dependencies |
| docs/ | ドキュメントだけの変更 | docs/update-api-guide |
| refactor/ | 動作を変えない内部構造の改善 | refactor/simplify-auth-service |
| test/ | テストコードの追加・修正 | test/add-order-service-tests |
| ci/ | CI/CD設定の変更 | ci/add-build-workflow |
| build/ | ビルド方法やビルドツールの変更 | build/update-gradle |
| perf/ | パフォーマンス改善 | perf/optimize-search-query |
| style/ | コードの整形など | style/apply-code-format |
| revert/ | 過去の変更の取り消し | revert/remove-login-change |
| spike/ | 技術調査や実験 | spike/test-new-cache |
「main」：安定したコードを管理するブランチ
「main」は、リポジトリの中心となるブランチです。GitHubで新しいリポジトリを作成した場合も、現在は「main」がデフォルトブランチ名として使われています。
一般的に「main」ブランチは次のような状態を維持します。
- テストが完了している
- ビルドが成功する
- 本番へリリースできる
- 直接作業せず、Pull Requestを経由して変更する
（余談）
古いリポジトリや一部のGit Flowの資料では、同じ役割に「master」という名前が使われています。
既存プロジェクトで「master」を使っている場合は、無理に変更する必要はありませんが、新規プロジェクトでは「main」を採用するケースが一般的です。
「develop」：次回リリースの変更を統合するブランチ
「develop」は、主にGit Flowで使われる長期ブランチです。
「main」が現在の安定版を表すのに対し、「develop」は次回リリースに含める開発中の変更を統合するブランチとして使われます。
Git Flowでは、通常、機能ブランチを「develop」から作成し、完成後に「develop」へ戻します。
「feature/」「feat/」：新しい機能を追加する
「feature/」「feat/」は、新しい機能や利用者にとって新しい価値を追加するときに使われます。
例えば、次のような変更が対象です。
- ログイン機能を追加する
- 検索条件を追加する
- CSV出力機能を追加する
- 新しいAPIを追加する
- 管理画面へ新しい操作を追加する
小さな機能追加でも、大きな機能追加でも使用できます。
ただし、一つのブランチへ関係のない機能を複数詰め込まないようにすることが重要です。一つのブランチは、一つの目的に絞った方がレビューしやすく、問題が起きた場合も変更を戻しやすくなります。
# 良い例
feature/add-password-reset
# 避けたい例
feature/add-password-reset-and-update-user-list-and-fix-order-bugちなみに、「feat/」は「feature/」の短縮形というだけです。どちらを使用しても技術的な違いはありません。
コミットメッセージの形式を定める以下記事でも新機能を表す種類として使用されています。そのため、コミットメッセージと表記を合わせて「feat/」を採用するチームもあります。
ただし重要なこととして、「feature/」と「feat/」を混在させず、どちらかへ統一しましょう。初めて見る人にも意味が伝わりやすいのは「feature/」、短さを優先する場合は「feat/」です。
「fix/」「bugfix/」：通常のバグを修正する
「fix/」「bugfix/」は、既存機能の不具合を修正するときに使います。
例えば、次のような変更が該当します。
- 特定条件で画面にエラーが表示される問題を直す
- 計算結果が誤っている問題を直す
- データが重複登録される問題を直す
- APIが不正なステータスを返す問題を直す
こちらも「fix/」「bugfix/」に技術的な違いはありません。どちらを採用してもOKですが、どちらかへ統一するようにしましょう。
「hotfix/」：本番環境の問題を緊急修正する
「hotfix/」は、本番環境で発生した重大な問題を緊急修正するときに使用します。
代表的な対象は、次のような問題です。
- 本番環境で決済できない
- 多くの利用者がログインできない
- データ破損につながる不具合がある
- 重大なセキュリティ問題がある
- サービスが停止している
「fix/」との違いは、修正内容よりも緊急性とリリース経路にあります。
通常の軽微なバグまで、すべて「hotfix/」にするのは避けましょう。「hotfix」が多用されると、本当に緊急性の高い対応を区別できなくなります。
| 種類 | 主な対象 | 対応の考え方 |
|---|---|---|
| fix/ | 通常の不具合 | 通常の開発・リリース手順で修正する |
| hotfix/ | 本番の重大障害 | 通常のリリースを待たず緊急で修正する |
Git Flowでは、「hotfix」ブランチを安定版の「main」から作成し、修正後に「main」と「develop」の両方へ反映します。
「release/」：リリース前の最終調整を行う
「release/」は、リリース予定の変更を固定し、最終確認や軽微な修正を行うためのブランチです。
リリースブランチでは、次のような作業を行います。
- バージョン番号を更新する
- リリースノートを作成する
- 最終テストで見つかった軽微な不具合を修正する
- ビルドや配布設定を確認する
- リリース対象を固定する
一般的には、バージョン番号やリリースを識別できる名前を付けます。
release/2.4.0
release/2026-08原則として、リリースブランチへ大きな新機能は追加しません。新機能を追加するとテスト対象が変わり、リリースの安定性を損なうためです。
「release/」は、複数機能をまとめて定期リリースする開発で有効です。一方、変更を随時「main」へマージして継続的にデプロイする場合は、リリースブランチを使用しないこともあります。
「chore/」：開発環境や依存関係を保守する
「chore/」は、新機能でもバグ修正でもない保守作業に使われます。
代表的な変更は次のとおりです。
- ライブラリのバージョンを更新する
- 不要なファイルを削除する
- 開発用設定を更新する
- コード解析ツールの設定を変更する
- リポジトリ内を整理する
ただし、「chore/」は意味が広いため、何でも「chore/」にまとめないようにします。ドキュメントなら「docs/」、CI/CDなら「ci/」、ビルドなら「build/」など、より明確な種類がある場合はそちらを使うと分かりやすくなります。
「docs/」：ドキュメントを変更する
「docs/」は、ソースコードの動作を変えず、ドキュメントだけを更新するときに使用します。
対象には、次のようなものがあります。
- READMEを更新する
- API仕様書を更新する
- セットアップ手順を追加する
- 誤字を修正する
- JavaDocなどの説明を改善する
機能変更と説明書の更新を同じブランチで行う場合は、主な目的に合わせて「feature/」や「fix/」を使用する方法もあります。
「refactor/」：動作を変えずに内部構造を改善する
「refactor/」は、利用者から見た機能を変えずに、コードの構造を改善するときに使用します。
例えば、次のような変更です。
- 大きなクラスを分割する
- 重複処理を共通化する
- メソッドや変数の名前を改善する
- 責務を整理する
- 読みやすさや保守性を改善する
バグ修正を伴う場合は「fix/」、新しい機能を追加する場合は「feature/」と使い分けは意識しましょう。
「test/」：テストコードを追加・修正する
「test/」は、主にテストコードだけを変更するときに使用します。
既存機能に不足していたテストを追加する場合や、テスト基盤を改善する場合に適しています。
本番コードの機能追加と一緒にテストを追加する場合は、ブランチを分けずに「feature/」の中へテストも含めるのが一般的です。
「ci/」「build/」：CI/CDやビルド設定を変更する
「ci/」は、GitHub ActionsなどのCI/CD設定を変更するときに使用します。
「build/」は、ビルドツールやビルド方法を変更するときに使用します。
プロジェクトによっては、これらを「chore/」へまとめることもあります。
CI/CDやビルド関連の変更が多いプロジェクトでは、「ci/」と「build/」を分けると目的が明確になります。
「perf/」：パフォーマンスを改善する
「perf/」は、機能を大きく変えずに性能を改善するときに使用します。
例えば、SQLを改善する、キャッシュを導入する、不要な通信を減らすといった作業が該当します。
「style/」：コードの見た目を整える
「style/」は、コードの動作を変えずに、インデント、空白、改行、フォーマットなどを修正するときに使われます。
ここでの「style」は、Web画面のCSSやデザイン変更を意味するとは限りません。画面デザインを変更して利用者から見た機能や表示が変わる場合は、「feature/」または「fix/」の方が適切なことがあります。
「revert/」：過去の変更を取り消す
「revert/」は、過去にマージした機能や修正を取り消すためのブランチです。
緊急で変更を戻す場合でも、状況によっては「hotfix/」を使用するチームもあります。
「revert/」は「取り消し」であることを明示したい場合に便利です。
「spike/」「experiment/」：技術調査や実験を行う
「spike/」や「experiment/」は、採用するか分からない技術を調査したり、試作したりするときに使用します。
実験結果をそのまま本番へ入れるのではなく、採用が決まった後に必要な実装を「feature/」などで作り直す運用もあります。
ブランチ命名時の注意点
チケット番号を含める
GitHub Issues、Jira、Redmine、Backlogなどで作業を管理している場合は、ブランチ名にチケット番号を含めると追跡しやすくなります。
feature/GH-123-add-login
fix/APP-456-correct-tax-calculation
docs/DOC-78-update-api-guideチケット番号を含めるメリットは、以下の通りです。
- ブランチと作業依頼を対応付けられる
- 仕様や受入条件を確認しやすい
- Pull Requestの元になった作業を探しやすい
- CI/CDや自動化ツールで番号を利用できる
チケット番号を先頭と説明のどちらへ置くかも統一しましょう。一覧で番号を見つけやすいのは、接頭辞の直後へチケット番号を置く形式です。
単語の区切りにはハイフンを使う
説明部分の単語は、ハイフンで区切る形式がよく使われます。
feature/add-user-login
fix/prevent-duplicate-order一方、次のような形式もGitでは使用できます。
feature/add_user_login
feature/addUserLogin何でもいいですが、スネークケースやキャメルケースを混在させると、ブランチ一覧が不統一になります。
小文字とハイフンを使う形式は、視認性が高く、OSによる大文字・小文字の扱いの違いも避けやすいため、無難な選択です。
チケット番号の大文字が必要な場合は、説明部分だけを小文字にします。
feature/APP-123-add-user-login英語の動詞を使って変更内容を表す
説明部分は、何を変更するのか分かる短い英語にします。
よく使われる動詞も記載しておきます。
| 動詞 | 意味 | 例 |
|---|---|---|
| add | 追加する | feature/add-login |
| update | 更新する | docs/update-api-guide |
| remove | 削除する | chore/remove-unused-files |
| improve | 改善する | test/improve-order-tests |
| prevent | 防止する | fix/prevent-duplicate-orders |
| support | 対応する | feature/support-csv-export |
| migrate | 移行する | chore/migrate-database-config |
| upgrade | バージョンを上げる | build/upgrade-gradle |
「feature/login」でも概要は伝わりますが、「feature/add-login」の方が、ログイン機能を追加することが明確です。
短くても意味が分かる名前にする
GitHub公式も、短く説明的なブランチ名を推奨しています。
長すぎる名前は、コマンド入力や画面表示で扱いにくくなります。
詳しい仕様はIssueやPull Requestに記載し、ブランチ名は作業を識別できる範囲に短くします。
# 長すぎる例
feature/APP-123-add-new-login-screen-with-email-and-password-validation-for-mobile-users
# 改善例
feature/APP-123-add-login-validationGitで使用できない文字に注意する
ブランチ名には、Gitの参照名として使用できない文字や形式があります。
Git公式の「git-check-ref-format」ドキュメントでは、主に次のような制約が示されています。
- スペースを含められない
- 「~」、「^」、「:」、「?」、「*」、「[」、バックスラッシュを含められない
- 「..」を含められない
- 「@{」を含められない
- 「/」で始めたり、終わったりできない
- 「//」のようにスラッシュを連続させられない
- 「.」で終わることはできない
- スラッシュで区切った要素を「.lock」で終わらせることはできない
- ブランチ名全体を「@」だけにすることはできない
技術的に使用できる特殊文字でも、シェルで特別な意味を持つ場合があります。英数字、ハイフン、スラッシュを中心にした単純な名前にすると、トラブルを避けやすくなります。
大文字・小文字を混在させない
次のように大文字・小文字を混在させたブランチを同時に作るのは避けましょう。
feature/add-login
Feature/add-login
FEATURE/add-loginファイルシステムによって大文字・小文字の扱いが異なるため、ローカル環境で問題が起きる可能性があります。また、人が見たときにも同じ種類なのか判断しにくくなります。
原則として、接頭辞と説明部分には小文字を使用し、チケット番号など必要な部分だけ大文字にするルールが分かりやすいでしょう。
おまけ：今のブランチ名形式が慣習となった背景
ここでは、どのような背景でこれらのブランチ名が慣習となったのかも記載しようと思います。
「feature/」、「hotfix/」などの名前が広く使われるようになった背景には、Gitの登場によるブランチ運用の変化、Git Flowの普及、GitHubを中心としたPull Request開発の普及があります。
ただし、現在使われているすべての接頭辞を、特定の1人が発明したわけではありません。Git Flowから直接広まった名前と、コミットメッセージなど別の慣習から影響を受けた名前が混在しています。
Git以前はブランチの作成とマージが重い作業だった
Git Flowの提唱者は元の記事で、CVSやSubversionなどが中心だった時代には、ブランチの作成やマージが難しい作業として扱われ、頻繁には行われていなかったと振り返っています。
Gitではブランチの作成や切り替えを軽量に行えます。そのため、1つの大きな開発ブランチへ全員の変更を集めるのではなく、機能や作業単位で短期間のブランチを作成し、完成後にマージして削除する方法が広まりました。
Gitの以下記載でも、1つの機能や関連作業のために作る短期間のブランチを「topic branch」と呼び、Gitでは日常的に作成・マージ・削除できると説明しています。
この「1つの目的につき1つの短期ブランチ」という考え方が、「feature/add-login」や「fix/payment-error」のような名前を付ける土台になりました。
Git Flowが役割別の名前を整理
2010年1月、Vincent Driessen氏がGit Flowのモデルを公開しました。
Git Flowとは何か・・・については以前記事にまとめているのでそちらを是非ご覧ください。
要はGitでチーム開発するときに「どのブランチを何の目的で使うか」を整理したブランチ運用モデルです。以下がGit Flowに従ったブランチの考え方になります。
| ブランチ名 | 意味 |
|---|---|
| master | 本番リリース可能な状態 |
| develop | 次回リリース向け変更の統合 |
| feature/ | 新機能の開発 |
| release/ | リリース準備 |
| hotfix/ | 本番の重大問題を予定外に緊急修正 |
このように用途を英語で直接表すことで、名前と役割の対応が分かりやすかったことがチームの共通ルールとして採用しやすかった理由の1つです。
特に「hotfix」は、通常のバグ修正ではなく、計画外で直ちに本番リリースする修正を表す言葉としてGit Flowの中で明確に位置付けられました。現在も「fix/」と「hotfix/」を緊急性で区別する慣習に、その考え方が残っています。
git-flowツールがスラッシュ形式を普及
Git Flowのモデルが公開された後、同じVincent Driessen氏によって、操作を補助するgit-flowコマンドライン拡張が開発されました。
Git Flowは考え方、git-flowコマンドラインはその操作を自動化するツールです。両者は同じものではありません。
元の記事では、featureブランチに「feature/」という接頭辞を必須としておらず、releaseブランチを「release-*」、hotfixブランチを「hotfix-*」の形式で説明していました。一方、git-flowツールの初期化画面では、次のような接頭辞がデフォルトとして使われるようになりました。
feature/
release/
hotfix/
support/Gitはブランチ名の中に「/」を使用でき、参照名を階層的にグループ化できます。そのため、種類と具体的な作業名を次のように分ける形式が定着しました。
画面やコマンドで同じ接頭辞のブランチをまとめて見つけやすいことも、スラッシュ形式が使われる理由です。
GitHub Flowの普及で短く説明的な作業ブランチも一般化
Git Flowは明確なリリース期間を持つ開発に適していますが、継続的デリバリーを行うWebサービスには複雑な場合があります。
GitHub Flowでは、「main」から作業用ブランチを作成し、Pull Requestを経由して「main」へ戻すシンプルな方法を採用します。この方法では、「develop」や「release/」を必ずしも使用しません。
GitHub Flowの公式資料は「increase-test-timeout」や「add-code-of-conduct」のような短く説明的な名前を例として示しています。これにより、Git Flow形式の接頭辞を使う方法と、作業内容だけを簡潔に表す方法の両方が広く使われるようになりました。
「master」から「main」への変化
長い間、多くのGitリポジトリでは、デフォルトブランチに「master」という名前が使われていました。そのため、2010年に公開されたGit Flowの元の記事でも、本番リリース用のブランチは「master」です。
その後、GitHubはデフォルトブランチ名を変更し、2020年10月1日から新規リポジトリのデフォルトを「main」にしました。
既存のリポジトリは自動変更されず、「master」を引き続き使用できたので現在も両方の説明が残っているわけです。
「main」と「master」にGitの機能上の違いはありません。どちらもプロジェクトがデフォルトブランチに付けた名前です。本記事では現在のGitHubに合わせて「main」を使用しています。
チケット番号付きの形式は課題管理との連携から広まった
「feature/APP-123-add-login」のようにチケット番号を入れる形式は、Git Flowそのものの必須ルールではありません。
GitHub Issues、Jira、Redmine、Backlogなどで要件や不具合を管理するチームが、ブランチ、Pull Request、チケットを追跡しやすくするために追加した慣習です。
feature/APP-123-add-login
feature ：作業の種類
APP-123 ：対応するチケット
add-login：変更内容最後に
さて今回は、GitHubでよく使われるブランチ命名の慣習についてまとめました。
プロジェクトの中では当たり前のように使われていますが、何で使われているかってよく分からないですもんね。しかも先輩方も周りに合わせて使っているだけでよく意図を分かっていない・・・なんてこともあったり。
意味が明確になると管理もしやすいと思いますのでこの機会に是非慣習的な部分を身に付けましょう！
以上！
GitHub関連の記事は他にもまとめていますので読んでもらえると嬉しいです！
その他の勉強記事も是非！
コメント