竹田奈央 
Git初心者だけど、
ブランチ名って何にすれば良いか悩む…
今回の記事は上記のような方におすすめ。
今回の記事では、Gitブランチの命名規則について…Git初心者でもわかるよう、わかりやすく解説いたします！
先輩に「適当につけといて…」と言われて一番困るものの１位がブランチ名ではないでしょうか。「適当って言われても、その適当がわからないから困ってるんだよ！」とキレたくなる方も多いかもしれません。ですが、本日は命名規則を７つ「厳選して」お伝えいたします！
気になる箇所あったらコメントで教えてね。
なおこの記事は3分で読める内容です。
🔥Gitブランチの命名ルールを統一するメリット
チーム内で命名のガイドラインを策定し、記述方法を統一することで、どんなメリットが得られるでしょうか？
- 過去の作業内容を素早く特定できる
- 誰が何をしているか一目で分かる
- ミスコミュニケーションの防止
一言で言えば「より開発を効率化する」ことが可能です。適切にブランチが命名がされていなければ、いざ過去のコードを探したい時にも検索にヒットしませんよね。そのため「探し物をする」というなんとも無駄なところで大幅に時間が取られてしまいます。
命名規則の短期的なメリットがあまりわからないかもしれませんが、長期的には必ずチーム開発にとって大きなプラスになります。ぜひ、これから紹介する命名規則を意識してブランチ名を決定してみてください！
Gitブランチの種類を理解しよう
７つの命名規則を紹介する前に、永続ブランチと一時ブランチの違いについて理解する必要があります。
永続ブランチ（長期間維持されるブランチ）
| ブランチ名 | 用途 |
|---|---|
main（またはmaster） | 本番用の安定ブランチ |
develop | 開発用ブランチ（mainへの中継） |
qa（任意） | テスト・検証用ブランチ |
- 永続ブランチ①：マスターブランチ
マスターブランチは、Git リポジトリのデフォルトのブランチです。本番用のブランチですね。本番用ですので、通常は開発したコードをいきなり「マスターブランチ」に取り込むようなことはありません。 - 永続ブランチ②：Dev ブランチ
「Devブランチ」は開発用のブランチです。通常、上記の「マスターブランチ」にいきなりマージされることはなく、「Devブランチ」にマージされ、テスト作業を経て、ようやく「マスターブランチ」にソースが取り込まれます。 - 永続ブランチ③：QA ブランチ（テストブランチ）
「Devブランチ」が開発者用のブランチであるのに対し、テストブランチはお客さんの本番前チェックに使用したりもします。ただ、案件によってはない場合もあります。
一時ブランチ（作業が終われば削除するブランチ）
| ブランチ名の接頭語 | 用途 |
|---|---|
| feature/ | 新機能開発 |
| hotfix/ | 緊急の不具合対応 |
一時的なブランチには、大きく分けて「Hot Fix：緊急バグ」「Feature Branches：新規機能開発」の2つがあります。
- 一時ブランチ①：feature/
新規機能開発用のブランチです。基本的には開発用ブランチ「develop」から「checkout」し作成後、再度「develop」へとマージします。 - 一時ブランチ②：hotfix/
緊急バグ修正用のブランチです。本番環境にて緊急度の高いバグが見つかった際に作成します。基本的には本番環境用の「main」から「checkout」し作成後、再度「main」へとマージします。
※ 「hotfix」については、「main」から「checkout」しており、開発環境にはバグ修正が取り込まれていないことになるので、mainマージ後に、適宜「develop」へもバックマージします。
これらは、機能追加や改修があるたびに、頻繁に追加・削除されるブランチとなります。特にGitHubを使用している場合は、ブランチをマージ後、画面から新しく作成したブランチを削除する運用をするチームも多いです。
Git ブランチ７つの命名規則【厳選】
それでは、７つの命名規則について厳選して紹介します。
- 命名規則①：カテゴリー名で始める
- 命名規則②：課題追跡IDを含める
- 命名規則③：ハイフンかスラッシュのセパレータを使用する
- 命名規則④：開発者名を使う
- 命名規則⑤：数字のみは避ける
- 命名規則⑥：複雑な命名規則を避ける
- 命名規則⑦：長いブランチ名を避ける
命名規則①：カテゴリー名（prefix）で始める
「hotfix/〇〇-▲▲-□□」や
「feature/▲▲-□□-●●」など、先頭で何をしているブランチなのかわかるようにします。
# ホットフィックスブランチ（緊急性の高いバグ）
git checkout -b hotfix/▲▲-□□-●●
# 新規機能開発ブランチ
git checkout -b feature/〇〇-▲▲-□□命名規則②：タスク追跡IDを含める
例えば、「Redmine」「Trello」「JIRA」など、あなたが案件で使用しているタスク管理ツールがありますよね。
そもそも課題管理ツールなんてないんですけど…！
課題管理ツールを使えば、ブランチとの紐付けで
色々便利機能が使えるので、まずは導入するところから始めてみてください
タスク管理ツールには、一意なIDがあるかと思います。「JIRA」であれば「task-01」のような。
ブランチ名にこれらのタスクIDを含めることで沢山のメリットが得られます。特に外部ツールの中には、ブランチ名やコメント名が連動して、便利機能が使えるものもあります。
マージされたタイミングで、
タスクを自動完了できる、なんて機能も使えますよ
# バグ修正ブランチ
git checkout -b bug-task-01-▲▲-□□
# 新規機能開発ブランチ
git checkout -b feature-task-02-▲▲命名規則③：ハイフンかスラッシュのセパレータを使用する
ハイフン（-）、スラッシュ（/）、アンダースコア（_）のどれをセパレータ（区切り文字）として使用しても問題ありません。
ただ、デプロイの時に「/」など、特定文字が禁止されているケースもあり、インフラ担当者と相談が必要な場合もあります。
ここで大事なのは、同じチーム内で使用するセパレータを統一することです。セパレータがあることで、ブランチが読みやすくなり、特に膨大なブランチを扱っている場合は、可読性アップにも繋がるので非常に重要です。
# ダメな例（読みにくい）
git checkout -b bugtask01▲▲□□
# 良い例１
git checkout -b feature-task-01-▲▲
# 良い例２
git checkout -b feature_task-01_▲▲
# 良い例３
git checkout -b feature/task-01/▲▲命名規則④：開発者名を含める（必要に応じて）
複数人で作業している場合、誰が担当しているかを明示するために開発者名を含めるのも有効です。ただしブランチ名に含めなくても、履歴を辿れば誰が開発したのかが分かるため、このブランチ運用が必要なケースは少ないかと思われます。
git checkout -b feature/yamada/123-add-dashboard必要な時としては、同一タスクの引き継ぎ時などでしょう。引き継ぎ時などはブランチ名が被るケースもあり、ぱっと見で区別するために名前を含むなどの用途が考えられます。
ただ、引き継ぐケースでは、そのままマージ前の同一ブランチを引き継ぐケースもあり、名前を含める必要がない場合もあります。詳細はチームメンバーと相談してみましょう。
命名規則⑤：数字のみは避ける
先ほど、タスクIDを含めると良いという話をしました。
しかし、IDのみの使用は混乱を招くことになるので良くありません。マージする際にも、IDだけでは大きなミスに繋がりかねません。まだ本番にマージしたくないブランチをマージしてしまって大事故につながる…なんて事態は避けたいですしね。
# 悪い例１
git checkout -b task-01
# 悪い例２
git checkout -b 00001
# 良い例
git checkout -b yamada-feature-task-01-▲▲ブランチの話とは少しそれてしまいますが、筆者のケースでは、すべてのコミットに「issueID」を含めることをルール化しているチームがありました。
理由としては、特にリリース直後など、リバートやバックマージなどが繰り返される時期において、同じ1つの機能なのにリリース漏れが発生することを防ぐためです。
命名規則⑥：複雑な命名規則を避ける
今まで、いくつか命名規則を紹介してきました。
ですが、同時に複数の命名規則を設けてしまうと混乱の原因になってしまいます。大事なのはチームメンバー内の一貫性を保つこと。
開発効率化のためのルールなのに、ルールを複雑化してしまっては本末転倒です。
# 悪い例（開発者名-カテゴリ名-タスクID-開発日時-関連テーブル名-内容）
git checkout -b yamada-feature-task-01-20211220-users-▲▲命名規則⑦：長いブランチ名を避ける
大事なのは、一貫性と正確性です。
ブランチ名が長すぎると、読むのにも時間がかかってしまい開発効率に悪影響です。自分でも読み切るのに時間がかかるぐらい長い場合は数単語に収められるよう（もしくはもっと短い単語がないか）考えてみましょう。
もうこれ以上短くできないのですが、
「shinzin-feature-task-01-correctly-and-concisely-add-address-and-zip-code-columns-to-user-tables」はだめですかね…？
（逆にどうしてそうなったのか…）
# 悪い例（もはや読む気がしない）
git checkout -b yamada-feature-task-01-correctly-and-concisely-add-address-and-zip-code-columns-to-user-tablesまとめ｜Gitブランチの命名は「一貫性」がカギ
以上、Gitブランチの命名規則についてのベストプラクティスをご紹介いたしました！
🔑 ポイントの再確認：
- 命名規則①：カテゴリー名で始める
- 命名規則②：課題追跡IDを含める
- 命名規則③：ハイフンかスラッシュのセパレータを使用する
- 命名規則④：開発者名を使う
- 命名規則⑤：数字のみは避ける
- 命名規則⑥：複雑な命名規則を避ける
- 命名規則⑦：長いブランチ名を避ける
チーム内で規約を設けて、全員が同じ認識を持つことで、理解の向上と開発速度向上につながるかと思います。ぜひ、今回の内容を参考にしてみてください。
また、あなたのチームの規約で、もっとおすすめのものがあったらぜひコメントにてご教示ください！お願いいたします。
ふー！！ ブランチ名考えるのに１時間使っちゃった！！
（深呼吸…）
また、Github Pagesを使ったブログ運営に興味のある方は、こちらの記事「【Github】Github Pagesでのブログ運営【長所と短所を解説】」や
「【Git】Git FlowとGitHub Flowの比較【開発効率化】」も、
エンジニアとしてのキャリアアップにご興味のある方は「リーダブルコードを読んだら成長が加速した話｜初心者エンジニアの必読書」や「中小SES→フリーランス→年収960万円。マッチングアプリで気づいた“自分だけ年収ヤバい”問題」もあわせてご覧ください！