Git 運用ブランチモデル

# ✅ チーム開発で使える 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` |

---

:::note

### 📌 「master」から「main」への移行について

Git では長らく、本番環境用のデフォルトブランチとして `master` が使われてきました。  
しかし、2020年以降、GitHub などのプラットフォームではより中立的な表現として `main` をデフォルトとする動きが広まりました。

現在では `main` を使うプロジェクトも増えていますが、本記事では当時の運用に基づき `master` を使用しています。必要に応じて読み替えてください。
:::

---

## 🌱 各ブランチの役割と運用ルール

### 🚀 master ブランチ

#### 命名規則

```
master
```

#### 特徴

- 本番環境にリリースされているコードを管理します。
- 直接コミットは行わず、`develop` などからマージして更新します。
- バージョンごとにタグを付けて管理します。
- 最新のコミットは、本番環境で稼働中のコードと一致していることが前提です。

---

### 🧪 develop ブランチ

#### 命名規則

```
develop/[バージョン番号]
```

#### 特徴

- 開発のベースとなるブランチです。
- `master` から派生し、`feature` ブランチはここから作成します。
- 複数の `feature` ブランチの成果を統合していきます。
- 軽微な修正は、管理者が直接コミットすることもあります。
- ステージング環境と同期していることが望ましいです。

---

### 🛠️ feature ブランチ

#### 命名規則

```
feature/[派生元バージョン番号]/[機能名、作業内容 等]
```

#### 特徴

- 中〜大規模な機能追加や改修作業に使用します。
- `develop` ブランチから派生し、バージョン番号を引き継ぎます。
- 実装する機能や作業者ごとにブランチを分けます（基本的に1チケット＝1ブランチ）。
- 作業完了後は `develop` にマージし、ブランチは削除します。
- ローカルで完結する軽微な修正の場合、リモートにプッシュしないこともあります。

```mermaid
gitGraph:
    commit id: "Ver.1.0.0 Release" tag: "Ver.1.0.0"
    branch develop/1.1.0
    commit id: "Ver.1.1.0"
    branch "feature/1.1.0/バグ修正"
    commit id: "修正１"
    commit id: "修正２"
    checkout develop/1.1.0
    branch "feature/1.1.0/追加機能"
    commit id: "機能追加"
    checkout develop/1.1.0
    merge "feature/1.1.0/バグ修正"
    checkout develop/1.1.0
    merge "feature/1.1.0/追加機能"
    checkout main
    merge develop/1.1.0 id: "Ver.1.1.0 Release" tag: "Ver.1.1.0"
```

---

### 🔧 hotfix ブランチ

#### 命名規則

```
hotfix/[バージョン番号]
```

#### 特徴

- 本番環境で発生した致命的なバグに対応するためのブランチです。
- `master` から派生し、修正後は `master` と `develop` の両方にマージします。
- 緊急対応のため、通常の `feature` ブランチとは別のフローで扱います。

```mermaid
gitGraph:
    commit id: "Ver.1.1.0 Release" tag: "Ver.1.1.0"
    branch develop/1.1.0
    branch hotfix/1.1.1
    commit id: "致命的なバグ修正"
    checkout develop/1.1.0
    merge hotfix/1.1.1 id: "Ver.1.1.1 Merge"
    checkout main
    merge hotfix/1.1.1 id: "Ver.1.1.1 Release" tag: "Ver.1.1.1"
```

---

## 🖥️ 作業環境の使い分け

### 💻 ローカル環境

- ソースの修正、コミット、ブランチ作成・マージなどの作業は基本的にローカルで行います。

### 🧪 ステージング環境

- ステージング環境では、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` にバージョンタグを付けて管理します。

---

# 🔗 参考サイト

- [Gitのブランチモデルについて][]
- [受託でやるのに程よいベストなGitのフローを考える][]
- [ぼくが実際に運用していたGitブランチモデルについて][]
- [A successful Git branching model を翻訳しました][]

[Gitのブランチモデルについて]: https://qiita.com/okuderap/items/0b57830d2f56d1d51692
[受託でやるのに程よいベストなGitのフローを考える]: https://qiita.com/sy_125/items/451c75bf900f23650324
[ぼくが実際に運用していたGitブランチモデルについて]: https://havelog.ayumusato.com/develop/git/e513-git_branch_model.html
[A successful Git branching model を翻訳しました]: http://keijinsonyaban.blogspot.com/2010/10/a-successful-git-branching-model.html