gitブランチ名の命名規則に悩んだらこれ

Last updated at 2026-01-29Posted at 2026-01-29

はじめに

現在私が所属しているチームでは、新しく作成されたブランチに対する命名規則ルールが存在しないため、周囲に合わせるようにそれっぽいブランチ名を命名していました。
このままではGitHubリポジトリ名同様、重複したブランチ名問題やブランチの管理が大変になることが予想されるため、公式ドキュメントおよび国際的に広く採用されているベストプラクティスを中心に、AIに調査させまとめてみました。

正解が存在するわけではないため、チームで決められたルールがあれば遵守しましょう。

結論

作成した変更の内容に応じたtype（プレフィックス）を使う（feature, bugfixなど）
関連するチケット、タスクがあればそのidを使う
変更の内容を3~5単語で英語表現する
<type>/<optional-id>-<short-description>のフォーマットでブランチを作成する

命名規則の目的と重要性

ブランチ名はコードの意図や目的を他の開発者に即時に伝えるためのもの
一貫した命名規則により、チームでの作業効率とコード品質レビューの効率が向上する
Git自体は命名規則を強制しないが、多くのワークフロー（Git Flow 等）で利用されている

一般的な命名構造

推奨構造

<type>/<optional-id>-<short-description>

optional-idには、該当するgit-issueやbacklogタスクのidがあれば使います

例:

feature/1234-add-user-authentication ✅️
bugfix/fix-login-button ✅️
hotfix/urgent-security-patch ✅️

ブランチの種類とプレフィックス

以下は一般的に使われるタイプ（prefix）です。
プレフィックスによりブランチの目的が明確になります。

種類(type)	説明
feature/	新機能開発
fix/	軽微なロジック修正
bugfix/	バグ修正
hotfix/	重大な緊急修正
release/	リリース準備用
refactor/	構造改善が目的
style/	見た目のみでロジック変更なし
perf/	パフォーマンス改善
chore/	軽微な調整
docs/	ドキュメント変更

命名ルール

①小文字と区切り文字

ブランチ名は小文字を使用し、単語間はハイフン-またはスラッシュ/で区切る。
そうすることで、GitHub の一部自動化ツールやシェル補完との相性も良い。

②説明は簡潔かつ有意義に

説明部分はそのブランチが何をするかを短く説明する。
あまり長くならないよう3~5単語以内を目安にするのが一般的。

③チケット番号を含める

Jira/GitHub Issues/ Backlogなどのチケット番号を入れるとトレース性が向上する。
CI/CDのトリガーやパイプライン名と連動しやすくなる。
ユニーク（一意）なブランチ名を作りやすくなる。

④特殊文字を避ける

スペース・アンダースコア・特殊記号は避けるのがベター。
GitLabや他CIでは特殊文字が制限される場合がある。

⑤代表的ワークフローとの関係

Git Flow は feature, develop, release, hotfix, main を定義する有名なワークフローである。
このワークフローに従うと、命名規則も自然に体系化される。

GitHubリポジトリ名の命名規則に関連するオススメ記事：
https://qiita.com/Hashimoto-Noriaki/items/5d990e21351b331d2aa1
https://zenn.dev/divsawa/articles/20251010-3_note-github-branch-myrules

AIが調査で参照したリンク：

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up