Gitブランチ戦略入門 - Git Flow/GitHub Flow/Trunk Based Development

はじめに

チーム開発において「どのようなブランチ構成で開発を進めるべきか」という問題に直面したことはありませんか。適切なGitブランチ戦略を選択することで、開発効率の向上、リリースの安定化、チームメンバー間のコンフリクト削減を実現できます。

本記事では、代表的な3つのGitブランチ戦略であるGit Flow、GitHub Flow、Trunk Based Developmentの特徴と使い分けを解説します。それぞれのブランチ戦略におけるfeature、develop、release、hotfixブランチの役割を理解し、プロジェクトの規模やリリース頻度に応じた最適な選択ができるようになることを目指します。この記事を読み終えると、以下のことができるようになります。

• 3つの代表的なGitブランチ戦略の特徴を説明できる
• プロジェクトに適したブランチ戦略を選択できる
• 各ブランチ（feature/develop/release/hotfix）の役割を理解できる
• チームにブランチ戦略を導入・運用できる

実行環境と前提条件

本記事の内容は、以下の環境で動作確認を行っています。

前提条件として、以下の知識があることを想定しています。

• コマンドライン操作の基礎知識（cd、ls/dir、mkdir等）
• テキストエディタの基本操作
• Gitの基本コマンド（git branch、git switch、git merge）の理解

Gitのバージョンは以下のコマンドで確認できます。

1

git --version

Gitブランチ戦略とは

ブランチ戦略が必要な理由

Gitブランチ戦略とは、チーム開発においてブランチをどのように作成・管理・統合するかを定めた規約です。ブランチ戦略を明確にすることで、以下のメリットが得られます。

• 開発の並行性向上: 複数の機能開発やバグ修正を同時に進められる
• リリースの安定化: 本番環境に影響を与えずに開発を進められる
• コードレビューの効率化: レビュー対象のスコープが明確になる
• トラブル時の対応迅速化: hotfixブランチなど緊急対応の手順が明確になる

ブランチ戦略の選択基準

ブランチ戦略を選択する際には、以下の要素を考慮する必要があります。

これらの要素に応じて、最適なブランチ戦略は異なります。次のセクションから、代表的な3つのブランチ戦略を詳しく見ていきましょう。

Git Flowブランチ戦略

Git Flowの概要

Git Flowは、2010年にVincent Driessen氏が提唱したブランチ戦略です。明確に役割が分かれた複数のブランチを使用し、厳格なルールに基づいて開発を進めます。定期的なリリースサイクルを持つプロジェクトに適しています。

gitGraph
   commit id: "init" tag: "v0.1.0"
   branch develop
   commit id: "d1"
   branch feature/A
   commit id: "f1"
   commit id: "f2"
   checkout develop
   merge feature/A id: "merge-A"
   branch release/1.0
   commit id: "r1"
   checkout main
   merge release/1.0 id: "v1.0.0" tag: "v1.0.0"
   checkout develop
   merge release/1.0 id: "d2"
   branch feature/B
   commit id: "f3"
   commit id: "f4"
   checkout develop
   merge feature/B id: "merge-B"
   checkout main
   branch hotfix/urgent
   commit id: "hf1"
   checkout main
   merge hotfix/urgent id: "v1.0.1" tag: "v1.0.1"
   checkout develop
   merge hotfix/urgent id: "d3"

Git Flowの5つのブランチタイプ

Git Flowでは、以下の5つのブランチタイプを使用します。

mainブランチ（旧master）

mainブランチは、本番環境にリリースされたコードを管理する永続的なブランチです。このブランチには常に安定したコードのみが存在し、直接コミットすることは禁止されています。

1
2
3

# mainブランチの確認
git switch main
git log --oneline

mainブランチへのマージは、releaseブランチまたはhotfixブランチからのみ行われます。マージ時にはタグを付与してリリースバージョンを記録します。

1
2
3

# リリースタグの付与
git tag -a v1.0.0 -m "Release version 1.0.0"
git push origin v1.0.0

developブランチ

developブランチは、次回リリースに向けた開発の統合先となる永続的なブランチです。featureブランチで開発された機能はすべてdevelopブランチにマージされます。

1
2
3
4

# developブランチの作成（初回のみ）
git switch main
git switch -c develop
git push -u origin develop

developブランチは常に最新の開発状態を反映しており、ここから新しいfeatureブランチやreleaseブランチが派生します。

featureブランチ

featureブランチは、新機能の開発やバグ修正を行う一時的なブランチです。developブランチから派生し、開発完了後にdevelopブランチへマージされます。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

# featureブランチの作成
git switch develop
git switch -c feature/user-authentication

# 開発作業
# ... コードの変更 ...
git add .
git commit -m "feat: ユーザー認証機能を追加"

# developへのマージ
git switch develop
git merge --no-ff feature/user-authentication
git branch -d feature/user-authentication

--no-ffオプションを使用することで、マージコミットが作成され、featureブランチの存在が履歴に残ります。

releaseブランチ

releaseブランチは、リリース準備を行う一時的なブランチです。developブランチから派生し、リリースに向けたバグ修正やドキュメント更新を行います。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20

# releaseブランチの作成
git switch develop
git switch -c release/1.0.0

# リリース準備作業
# ... バグ修正、バージョン番号更新 ...
git add .
git commit -m "chore: バージョン番号を1.0.0に更新"

# mainへのマージとタグ付け
git switch main
git merge --no-ff release/1.0.0
git tag -a v1.0.0 -m "Release version 1.0.0"

# developへのマージ
git switch develop
git merge --no-ff release/1.0.0

# releaseブランチの削除
git branch -d release/1.0.0

releaseブランチを作成することで、リリース準備と並行して次のバージョンの機能開発をdevelopブランチで継続できます。

hotfixブランチ

hotfixブランチは、本番環境の緊急バグ修正を行う一時的なブランチです。mainブランチから派生し、修正完了後にmainブランチとdevelopブランチの両方にマージされます。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20

# hotfixブランチの作成
git switch main
git switch -c hotfix/critical-security-fix

# 緊急修正
# ... バグ修正 ...
git add .
git commit -m "fix: セキュリティ脆弱性を修正"

# mainへのマージとタグ付け
git switch main
git merge --no-ff hotfix/critical-security-fix
git tag -a v1.0.1 -m "Hotfix version 1.0.1"

# developへのマージ
git switch develop
git merge --no-ff hotfix/critical-security-fix

# hotfixブランチの削除
git branch -d hotfix/critical-security-fix

Git Flowのメリットとデメリット

Git Flowには以下のメリットとデメリットがあります。

Git Flowが適しているプロジェクト

Git Flowは以下のようなプロジェクトに適しています。

• 明確なリリースサイクル（月次、四半期など）がある
• 複数のバージョンを同時にサポートする必要がある
• パッケージソフトウェアやモバイルアプリの開発
• 大規模チーム（10人以上）での開発
• 厳格なリリースプロセスが求められる

GitHub Flowブランチ戦略

GitHub Flowの概要

GitHub Flowは、GitHubが提唱するシンプルなブランチ戦略です。mainブランチとfeatureブランチのみを使用し、Pull Requestを中心としたワークフローで開発を進めます。継続的デリバリーを実践するWebアプリケーション開発に適しています。

gitGraph
   commit id: "m1"
   branch feature/A
   commit id: "a1"
   commit id: "a2"
   checkout main
   merge feature/A id: "m2"
   branch feature/B
   commit id: "b1"
   commit id: "b2"
   checkout main
   merge feature/B id: "m3"
   branch feature/C
   commit id: "c1"
   commit id: "c2"
   checkout main
   merge feature/C id: "m4"

GitHub Flowの6つのステップ

GitHub Flowは、以下の6つのステップで構成されます。

ステップ1: ブランチを作成する

mainブランチから新しいfeatureブランチを作成します。ブランチ名は作業内容がわかる簡潔な名前にします。

1
2
3
4

# featureブランチの作成
git switch main
git pull origin main
git switch -c add-login-feature

ステップ2: 変更をコミットする

featureブランチで変更を加え、意味のある単位でコミットします。

1
2
3
4
5
6

# 変更の追加とコミット
git add .
git commit -m "feat: ログイン画面のUIを実装"

git add .
git commit -m "feat: ログインAPIとの連携を実装"

ステップ3: Pull Requestを作成する

開発が完了したら、GitHubでPull Requestを作成します。

1
2

# リモートにプッシュ
git push -u origin add-login-feature

プッシュ後、GitHub上でPull Requestを作成し、変更内容の説明とレビュー依頼を行います。

ステップ4: レビューとディスカッション

チームメンバーがコードレビューを行い、フィードバックをコメントします。必要に応じて追加のコミットを行います。

1
2
3
4

# レビューコメントへの対応
git add .
git commit -m "fix: レビュー指摘事項を修正"
git push

ステップ5: デプロイとテスト

Pull Requestがマージされる前に、featureブランチをステージング環境にデプロイしてテストを行うことができます。

ステップ6: mainブランチにマージ

レビューが承認されたら、Pull Requestをmainブランチにマージし、featureブランチを削除します。

1
2
3
4

# マージ後のローカル更新
git switch main
git pull origin main
git branch -d add-login-feature

GitHub Flowのメリットとデメリット

GitHub Flowには以下のメリットとデメリットがあります。

GitHub Flowが適しているプロジェクト

GitHub Flowは以下のようなプロジェクトに適しています。

• 継続的デリバリー/デプロイメントを実践している
• Webアプリケーションやサービスの開発
• 小〜中規模チーム（2〜10人程度）での開発
• 頻繁なリリース（日次・週次）を行う
• 単一バージョンのみをサポートすればよい

Trunk Based Developmentブランチ戦略

Trunk Based Developmentの概要

Trunk Based Development（TBD）は、すべての開発者が単一のtrunk（main）ブランチに対して直接コミットするか、非常に短命なfeatureブランチを使用するブランチ戦略です。GoogleやFacebookなどの大規模組織でも採用されており、継続的インテグレーションと継続的デリバリーを最大限に活かすことができます。

gitGraph
   commit id: "m1"
   branch feature1
   commit id: "f1"
   checkout main
   merge feature1 id: "m2"
   commit id: "m3"
   branch feature2
   commit id: "f2"
   checkout main
   merge feature2 id: "m4"
   commit id: "m5"
   branch feature3
   commit id: "f3"
   checkout main
   merge feature3 id: "m6"

featureブランチは数時間～1日程度の短命でmainにマージされます。

小規模チーム向けTrunk Based Development

小規模チーム（2〜3人程度）では、featureブランチを使わずにmainブランチへ直接コミットすることも可能です。

1
2
3
4
5
6
7
8

# mainブランチに直接コミット
git switch main
git pull origin main

# 変更を加えてコミット
git add .
git commit -m "feat: 検索機能を追加"
git push origin main

この方式では、以下の点に注意が必要です。

• コミット前に必ずテストを実行する
• 小さな変更を頻繁にコミットする
• ビルドを壊さない責任を各開発者が持つ

スケールドTrunk Based Development

チーム規模が大きくなると、短命なfeatureブランチとPull Requestを組み合わせた方式を採用します。featureブランチは1〜2日以内にマージすることを目標とします。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

# 短命なfeatureブランチの作成
git switch main
git pull origin main
git switch -c feature/add-filter

# 小さな変更をコミット
git add .
git commit -m "feat: フィルター機能のUIを追加"
git push -u origin feature/add-filter

# Pull Request作成後、レビューを受けてマージ
# 通常1日以内にマージを完了

フィーチャーフラグの活用

Trunk Based Developmentでは、未完成の機能をmainブランチにマージしながらも本番環境では非表示にするため、フィーチャーフラグ（Feature Flags）を活用します。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

// フィーチャーフラグの例
const features = {
  newSearchUI: false,  // 新しい検索UIは開発中
  darkMode: true,      // ダークモードは有効
};

function renderSearch() {
  if (features.newSearchUI) {
    return <NewSearchComponent />;
  }
  return <LegacySearchComponent />;
}

フィーチャーフラグを使用することで、以下のメリットが得られます。

• 未完成の機能を安全にデプロイできる
• A/Bテストが容易になる
• 問題が発生した場合にすぐに機能を無効化できる

リリースブランチの運用

Trunk Based Developmentでもリリースブランチを使用する場合があります。ただし、Git Flowのreleaseブランチとは異なり、mainブランチからカットされた後は最小限の変更（バグ修正のみ）に限定されます。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

# リリースブランチの作成
git switch main
git switch -c release/2.0

# リリースブランチでのバグ修正
git cherry-pick <commit-hash>  # mainからの修正を取り込む

# または、mainで修正してからcherry-pick
git switch main
git add .
git commit -m "fix: 重大なバグを修正"
git switch release/2.0
git cherry-pick <commit-hash>

Trunk Based Developmentのメリットとデメリット

Trunk Based Developmentには以下のメリットとデメリットがあります。

Trunk Based Developmentが適しているプロジェクト

Trunk Based Developmentは以下のようなプロジェクトに適しています。

• 継続的デリバリーを極限まで追求したい
• 成熟したCI/CD環境がある
• 高い技術力とチームの信頼関係がある
• 頻繁なリリース（1日複数回）を行う
• DevOps文化が浸透している

3つのGitブランチ戦略の比較

比較表

3つのGitブランチ戦略を様々な観点から比較します。

プロジェクト特性別の推奨戦略

プロジェクトの特性に応じた推奨ブランチ戦略を以下に示します。

flowchart TD
    A["リリース頻度は?"] --> B{"月次以下?"}
    B -->|はい| C[Git Flow]
    B -->|いいえ（週次以上）| D{"広10CI/CD環境は成熟?"}
    D -->|No| E[GitHub Flow]
    D -->|Yes| F{"チームは高度なGitスキルを持つ?"}
    F -->|No| G[GitHub Flow]
    F -->|Yes| H[Trunk Based Development]

移行パスの考え方

チームの成熟度に応じて、ブランチ戦略を段階的に移行することも可能です。

1. 入門段階: GitHub Flowでシンプルな運用を始める
2. 安定段階: 必要に応じてGit Flowへ移行、またはGitHub Flowを継続
3. 成熟段階: CI/CD環境が整ったらTrunk Based Developmentへ移行

ブランチ戦略導入時の注意点

チーム全員の合意形成

ブランチ戦略を導入する際には、チーム全員がルールを理解し合意することが重要です。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

# ブランチ戦略ドキュメント（例）

## 採用戦略
GitHub Flow

## ブランチ命名規則
- feature/: 新機能開発
- fix/: バグ修正
- docs/: ドキュメント更新

## マージルール
- Pull Request必須
- 1名以上のレビュー承認必須
- CIがすべてパスすること

段階的な導入

一度にすべてのルールを適用するのではなく、段階的に導入することをお勧めします。

1. まずはブランチの命名規則から始める
2. Pull Requestのルールを追加する
3. CI/CDとの連携を強化する
4. 必要に応じてルールを調整する

ツールの活用

ブランチ戦略の運用を支援するツールを活用しましょう。

1
2
3
4
5
6
7
8

# git-flowの初期化（Git Flow採用時）
git flow init

# featureブランチの開始
git flow feature start user-profile

# featureブランチの完了
git flow feature finish user-profile

まとめ

本記事では、Git Flow、GitHub Flow、Trunk Based Developmentの3つの代表的なGitブランチ戦略について解説しました。

Git Flowは厳格なリリース管理が必要な大規模プロジェクトに適しており、develop、release、hotfixなど明確な役割を持つブランチを使用します。GitHub Flowはシンプルさを重視し、継続的デリバリーを実践するWebアプリケーション開発に最適です。Trunk Based Developmentは、成熟したCI/CD環境を持つチームが最速のリリースサイクルを実現するための戦略です。

どのブランチ戦略を選択するかは、チームの規模、リリース頻度、技術的成熟度、プロダクトの性質によって異なります。まずはシンプルなGitHub Flowから始め、プロジェクトの要件に応じて調整していくことをお勧めします。重要なのは、チーム全員がブランチ戦略を理解し、一貫して運用することです。

参考リンク

• A successful Git branching model（Git Flow原典）
• GitHub flow - GitHub Docs
• Trunk Based Development
• Comparing Git workflows - Atlassian
• Gitflow Workflow - Atlassian
• Git公式ドキュメント - ブランチ