竹田奈央 
Git初心者だけど、
ブランチ名って何にすれば良いか悩む…
今回の記事は上記のような方におすすめ。
今回の記事では、Gitブランチの命名規則について…Git初心者でもわかるよう、わかりやすく解説いたします！
先輩に「適当につけといて…」と言われて一番困るものの１位がブランチ名ではないでしょうか。「適当って言われても、その適当がわからないから困ってるんだよ！」とキレたくなる方も多いかもしれません。ですが、本日は命名規則を７つ「厳選して」お伝えいたします！
気になる箇所あったらコメントで教えてね。
本記事の内容
なおこの記事は3分で読める内容です。
命名規則のメリット【開発効率化！】
チーム内で命名のガイドラインを策定し、記述方法を統一することで、どんなメリットが得られるでしょうか？
一言で言えば「より開発を効率化する」ことが可能です。適切にブランチが命名がされていなければ、いざ過去のコードを探したい時にも検索にヒットしませんよね。そのため「探し物をする」というなんとも無駄なところで大幅に時間が取られてしまいます。
命名規則の短期的なメリットがあまりわからないかもしれませんが、長期的には必ずチーム開発にとって大きなプラスになります。ぜひ、これから紹介する命名規則を意識してブランチ名を決定してみてください！
永続ブランチと一時ブランチ
７つの命名規則を紹介する前に、永続ブランチと一時ブランチの違いについて理解する必要があります。
永続ブランチ①：マスターブランチ
マスターブランチは、Git リポジトリのデフォルトのブランチです。本番用のブランチですね。本番用ですので、通常は開発したコードをいきなり「マスターブランチ」に取り込むようなことはありません。
永続ブランチ②：Dev ブランチ
「Devブランチ」は開発用のブランチです。
通常、上記の「マスターブランチ」にいきなりマージされることはなく、「Devブランチ」にマージされ、テスト作業を経て、ようやく「マスターブランチ」にソースが取り込まれます。
永続ブランチ③：QA ブランチ（テストブランチ）
「Devブランチ」が開発者用のブランチであるのに対し、テストブランチはお客さんの本番前チェックに使用したりもします。ただ、案件によってはない場合もあります。
一時ブランチ：３つ
一時的なブランチには、大きく分けて「Bug Fix：バグ」「Hot Fix：緊急バグ」「Feature Branches：新規機能開発」の３つがあります。これらは、機能追加や改修があるたびに、頻繁に追加・削除されるブランチとなります。
Git ブランチ７つの命名規則【厳選】
それでは、７つの命名規則について厳選して紹介します。
命名規則①：カテゴリー名で始める
「bug-〇〇-▲▲-□□」や
「feature-▲▲-□□-●●」など、先頭で何をしているブランチなのかわかるようにします。
# バグ修正ブランチ
git checkout -b bug-〇〇-▲▲-□□
# ホットフィックスブランチ（緊急性の高いバグ）
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 yamada-feature-task-01-▲▲命名規則⑤：数字のみは避ける
先ほど、タスクIDを含めると良いという話をしました。
しかし、IDのみの使用は混乱を招くことになるので良くありません。マージする際にも、IDだけでは大きなミスに繋がりかねません。まだ本番にマージしたくないブランチをマージしてしまって大事故につながる…なんて事態は避けたいですしね。
# 悪い例１
git checkout -b task-01
# 悪い例２
git checkout -b 00001
# 良い例
git checkout -b yamada-feature-task-01-▲▲命名規則⑥：複雑な命名規則を避ける
今まで、いくつか命名規則を紹介してきました。
ですが、同時に複数の命名規則を設けてしまうと混乱の原因になってしまいます。大事なのはチームメンバー内の一貫性を保つこと。
開発効率化のためのルールなのに、ルールを複雑化してしまっては本末転倒です。
# 悪い例（開発者名-カテゴリ名-タスク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ブランチの命名規則についてのベストプラクティスをご紹介いたしました！
チーム内で規約を設けて、全員が同じ認識を持つことで、理解の向上と開発速度向上につながるかと思います。ぜひ、今回の内容を参考にしてみてください。
また、あなたのチームの規約で、もっとおすすめのものがあったらぜひコメントにてご教示ください！お願いいたします。
ふー！！ ブランチ名考えるのに１時間使っちゃった！！
（深呼吸…）
また、Github Pagesを使ったブログ運営に興味のある方は、こちらの記事「【Github】Github Pagesでのブログ運営【長所と短所を解説】」や「【Git】Git FlowとGitHub Flowの比較【開発効率化】」もあわせてご覧ください！