Gitフローとブランチ命名規則

はじめに

チームで開発を進める際、Gitフローを採用すると効率的でスムーズな作業が可能になります。そして、その効果を最大限に引き出すためには、わかりやすい「ブランチの命名規則」を守ることが重要になります。

と書きながらも、これは自戒になります。
つい最近、PRを出すタイミングで命名規則を意識しない自己流でブランチに名前をつけてしまいました。

今後、命名規則に従ったブランチの作成が出来るように、調べたことをまとめていくことにしました。

本記事では、Gitフロー・GitHubフローの概要を簡単に説明した後、チーム開発で役立つブランチ命名規則をわかりやすく解説します。

まず、GitHubフローとは？

GitHubフローは、軽量でシンプルなGit運用手法で、以下のステップで構成されます。

1. メインブランチは常にデプロイ可能

   • プロジェクトの基盤となるブランチで、常にリリース可能な状態を保ちます。

2. 新しい機能や修正ごとにブランチを作成

   • 作業内容ごとに分離したブランチを用意し、後から簡単に管理できるようにします。

3. コミットをこまめに行う

   • 作業の進捗を小さな単位で記録し、トラブルが発生した際に原因を特定しやすくします。

4. プルリクエストを作成してレビューを依頼

   • コードの品質を確保し、チームメンバーの知識共有を進めます。

5. コードレビュー後にマージ

   • レビューを通過したブランチのみをメインブランチに統合します。

6. デプロイ

   • リリース可能なコードが整ったら、メインブランチを基にデプロイします。

この流れを通じて、効率的な開発サイクルを実現できます。

Git Flowとの違い

GitHubフローがシンプルな運用を重視している一方で、Git Flowでは「master」「develop」「release」など複数のブランチを明確に区別します。

以下の画像のようなイメージになります。

普段、ブランチを切って作業をしている場所がfeatureブランチと考えてよいでしょう。それ以外はリリースや修正に関するブランチになります。
これからGit Flowにのっとって作業をするために、上の画像のような流れがあることを念頭に置いておきましょう。

では、ブランチの種類について見ていきます

masterブランチ

• 常にリリース可能な状態を維持するブランチです。開発者が直接コミットを行うことはなく、リリース準備が整った他のブランチ（例: releaseブランチやhotfixブランチ）からマージされます。
• リリース時には、Gitのタグ機能を使ってバージョン番号（例: v1.0.0）を付加し、リリースの履歴を明確に管理します。

developブランチ

• 開発中コードの中心となるブランチで、次期リリースに向けた全ての変更が集約されます。
• 開発者はこのブランチを起点にしてfeatureブランチを作成し、新しい機能の実装や改善を行います。作業が完了したら、レビューやテストを経てdevelopブランチに統合します。

featureブランチ

• 新しい機能を開発するための一時的なブランチです。developブランチを起点に作成し、作業内容を明確にするために「feature/xxx」のような命名規則を用います（例: feature/add-login）。
• 作業が完了した後、変更内容をdevelopブランチにマージします。これにより、mainブランチには安定した状態のコードだけが反映されるよう管理できます。

特徴

• 他の開発者と並行して作業しやすい。
• 作業内容が明確になるため、コードレビューやバグ追跡が容易になる。

releaseブランチ

• リリース準備専用のブランチで、開発中コード（developブランチ）をリリース可能な状態に仕上げるために使用します。
• 主にバージョン番号の管理や軽微な修正を行い、リリース前の最終確認を実施します。ただし、仕様変更や大きな機能追加はこのブランチでは行いません。
• リリースが完了したら、releaseブランチをmasterブランチにマージし、同時にdevelopブランチにも反映させます。

hotfixブランチ

• リリース済みのコードにおける重大なバグや緊急修正を行うための一時的なブランチです。masterブランチを起点に作成します。
• 修正内容はできる限り小規模で限定的なものに留め、素早くリリースできるようにします。修正が完了したら、まずmasterブランチにマージして即時リリースを行い、同時にdevelopブランチにも反映させます。

特徴

• ユーザーへの影響を最小限に抑えるため、迅速な対応を優先します。
• リリース後にコードの一貫性を保つため、修正内容を必ずdevelopブランチにも適用します。
• 命名規則として「hotfix/xxx」を用います（例: hotfix/fix-login-bug）。

リリース作業の例

# リリースブランチの作成
git flow release start 1.0.0

# 作業後、リリースを終了してマージ
git flow release finish 1.0.0

この操作により、masterブランチにバージョンタグが付与され、リリースが完了します。

ブランチの命名規則

GitHubフローやGit Flowを効率的に運用するには、ブランチ名を見ただけで内容がわかるようにすることが重要になります。以下に、基本ルールとよく使われる命名パターンを紹介します。

命名の基本ルール

わかりやすい名前
意味の伝わる名前をつける。例えば、 feature/add-login はOKだけど、branch1 はNGみたいな。

一貫性を保つ
命名フォーマットをチームで統一する（例: 英小文字、単語間はハイフンで区切る）。

具体的な命名パターン

上の説明と繰り返しになる部分あるかもですが、大事なことなので2回書きます。

機能追加ブランチ

• パターン: feature/xxx
• 例:
  • feature/add-login
  • feature/update-user-profile

リリースブランチ

• パターン: release/xxx
• 例:
  • release/1.0.0
  • release/20241219

緊急対応ブランチ

• パターン: hotfix/xxx
• 例:
  • hotfix/fix-critical-bug
  • hotfix/security-patch

下のこの画像は、僕が以前、GitHubのPR作成について理解するために書いた記事で作成したリポジトリの様子なのですが、ブランチ一覧を確認してみると、、、

ひどいですね。ブランチ名を見ても何も伝わってきません。

間違ってもこんな名前の付け方をしてはいけません。

さいごに

この命名規則に則ることに加えて、自分の参加しているプロジェクトのブランチ一覧を確認して、メンバーがどんな命名をしているのかも確認するのが大事かなと思いました

今回、この記事を書いたからには今後はしっかりとGit Flow、命名規則を意識して作業していきます！！

最後までお読みいただきありがとうございました。

参考文献