✅ チーム開発で使える Git 運用ブランチモデルの整理メモ
📝 はじめに
チーム開発において Git のブランチ運用は非常に重要です。
本記事では、実際に社内で運用していたブランチモデルをベースに、Qiita向けにわかりやすく整理しました。
- 対象読者：Git の基本操作はわかるけど、チームでの運用ルールに悩んでいる方
-
この記事でわかること：
- ブランチの種類と役割
- 開発〜本番反映までの流れ
- よくある運用上の注意点
🌿 ブランチ構成の全体像
以下の4種類のブランチを使い分けて運用します：
| ブランチ名 | 用途 | 派生元 | 命名規則例 |
|---|---|---|---|
master |
本番環境用 | - | master |
develop |
開発のベース | master |
develop/1.2.0 |
feature |
機能追加・改修用 | develop |
feature/1.2.0/login-ui |
hotfix |
緊急バグ修正用 | master |
hotfix/1.2.1 |
🌱 各ブランチの役割と運用ルール
🚀 master ブランチ
命名規則
master
特徴
- 本番環境にリリースされているコードを管理します。
- 直接コミットは行わず、
developなどからマージして更新します。 - バージョンごとにタグを付けて管理します。
- 最新のコミットは、本番環境で稼働中のコードと一致していることが前提です。
🧪 develop ブランチ
命名規則
develop/[バージョン番号]
特徴
- 開発のベースとなるブランチです。
-
masterから派生し、featureブランチはここから作成します。 - 複数の
featureブランチの成果を統合していきます。 - 軽微な修正は、管理者が直接コミットすることもあります。
- ステージング環境と同期していることが望ましいです。
🛠️ feature ブランチ
命名規則
feature/[派生元バージョン番号]/[機能名、作業内容 等]
特徴
- 中〜大規模な機能追加や改修作業に使用します。
-
developブランチから派生し、バージョン番号を引き継ぎます。 - 実装する機能や作業者ごとにブランチを分けます（基本的に1チケット＝1ブランチ）。
- 作業完了後は
developにマージし、ブランチは削除します。 - ローカルで完結する軽微な修正の場合、リモートにプッシュしないこともあります。
🔧 hotfix ブランチ
命名規則
hotfix/[バージョン番号]
特徴
- 本番環境で発生した致命的なバグに対応するためのブランチです。
-
masterから派生し、修正後はmasterとdevelopの両方にマージします。 - 緊急対応のため、通常の
featureブランチとは別のフローで扱います。
🖥️ 作業環境の使い分け
💻 ローカル環境
- ソースの修正、コミット、ブランチ作成・マージなどの作業は基本的にローカルで行います。
🧪 ステージング環境
- ステージング環境では、Git 管理下のフォルダは「プル専用」とし、直接編集は行いません。
- 別のフォルダにクローンしたリポジトリで開発やテストを行うことは問題ありません。
🚢 本番環境
- 本番環境もステージングと同様に、Git 管理下のフォルダは「プル専用」とします。
🔄 開発作業手順
このセクションでは、Git を使った開発作業の流れを、GUI ツールを利用するケースも想定しながら説明します。
1️⃣ 事前準備
- リモートリポジトリをクローンして、作業用フォルダを作成します。
-
developブランチに切り替え、最新の状態を取得します。
masterブランチがdevelopよりも先行している場合、管理者が新しいバージョン番号でdevelopブランチを作り直すことがあります。
2️⃣ 改修作業
- develop
ブランチから作業用のfeatureブランチを作成し、作業を開始します。 ブランチ名は「feature/バージョン番号/機能名」の形式にします（例：feature/1.2.0/login-ui`）。 - Git に不慣れなメンバーがいる場合は、管理者がリモートにブランチを作成し、作業者はそれをチェックアウトして作業を始めることもあります。
- ソースコードを修正し、意味のある単位でコミットしていきます。
- 修正が完了したら、リモートリポジトリにプッシュします。
軽微な修正で、すぐにdevelopにマージする場合は、ローカルのみで完結することもあります。
3️⃣ 修正内容の取り込み
- 作業が完了した
featureブランチの内容をレビューします。 - 問題がなければ
developブランチにマージします。- すべてのコミットを取り込む場合は「マージ」、一部のみ取り込む場合は「チェリーピック」を使用します。
- マージ後、
developブランチをリモートに反映します。
4️⃣ ステージング環境でのテスト
- ステージング環境にアクセスし、
developブランチを最新の状態に更新します。 - ステージング環境で動作確認を行います。
- テストが完了し問題なければ、
developの内容をmasterにマージします。
ステージングと本番で異なる設定（ファイルパスなど）が混ざらないように注意します。
5️⃣ 本番環境への反映
- 本番環境にアクセスし、
masterブランチを最新の状態に更新します。 - 本番環境への反映が完了したら、使用済みの
featureブランチを削除します。 - 必要に応じて、
masterにバージョンタグを付けて管理します。