🐶

ブランチ戦略について(Githubフロー)

に公開
GitHub
ブランチ
idea

はじめましてnorman6464 です。
今回は初めてチーム開発をするので、ブランチ戦略について解説していきます。

複数人で開発するとき、コードの変更を安全に管理するためには「どのようにブランチを切り、どうマージしていくか」を明確にする必要があります。
そのために役立つのが ブランチ戦略（Branching Strategy） です。

本記事では、代表的な戦略の中から GitHub Flow（Githubフロー） について詳しく紹介します。

ブランチ戦略とは

ブランチ戦略とは、GitHub 上の main（デフォルトブランチ）とは別に、以下のような目的ごとにブランチを切り、最終的に Pull Request（PR）を通して main へマージする一連の手順のことです。

  • 機能追加
  • リファクタリング
  • バグ修正
  • 設定変更 など

main への直接 push を禁止し、必ずブランチ→PR→レビュー→main へマージという流れにすることで、破壊的な変更を防ぎ安全に開発を行えます。

GitHub Flow とは？

GitHub Flow は GitHub が推奨している、シンプルで軽量なブランチ戦略です。
トピックブランチを活用し、短期間での開発サイクルを回すことに適しています。

複雑なブランチ構造を必要とせず、Web サービスやアジャイル開発など「高速で変更を反映したい」場面でよく使われます。

GitHub Flow の特徴

GitHub Flow には次の 6 つの基本ルールがあります。

  1. main は常にデプロイ可能な状態に保つ
  2. すべての作業は main から派生したトピックブランチで行う
  3. main への直接コミットは禁止
  4. 作業が終わったら PR（Pull Request）を作成する
  5. レビュー・テスト後に main へマージする
  6. 役割を終えたトピックブランチは削除する

ポイントは ブランチを短命に保ち、小さく素早く開発を進めること です。

GitHub Flow の開発サイクル（実例）

▼ トピックブランチの作成

# main から派生
git checkout -b feature/add-login

▼ 作業してコミット

git add .
git commit -m "Add login feature"

▼ GitHub 上へプッシュ

git push origin feature/add-login

▼ PR を作成してレビュー依頼
GitHub 上で Pull Request を作成し、レビューしてもらいます。

▼ main にマージ → デプロイ
レビュー OK・テスト OK になれば main へマージします。

▼ ブランチ削除

git branch -d feature/add-login

イメージ図にするとこのようになる

                       （常にデプロイ可能）
                           +-----------+
                           |   main    |
                           +-----------+
                                 |
        -------------------------------------------------
        |                                               |
        v                                               v
+-------------------+                         +--------------------+
| feature/add-login |                         | feature/fix-header |
+-------------------+                         +--------------------+
        |                                               |
        | commit → push                                 | commit → push
        v                                               v
+----------------------+                       +-----------------------+
| Pull Request (PR#1) |                       | Pull Request (PR#2)   |
+----------------------+                       +-----------------------+
        |                                               |
        | Review & Test                                 | Review & Test
        v                                               v
                           +-----------+
                           |   main    |  ← 両方の PR を順次マージ
                           +-----------+
                                 |
                                 | デプロイ（任意）
                                 |
                          （ブランチ削除）

GitHub Flow のメリット

小さな単位で開発を進められるため変更の追跡がしやすい

PR ベースの開発でレビューが活発になる

ブランチ構造がシンプルで、初学者でも理解しやすい

短いサイクルで開発 → マージ → デプロイが可能
→ 特に Web サービスやアジャイルに最適

GitHub Flow のデメリット

複雑なリリース管理には向いていない

例：複数バージョンの同時保守、ステージング環境の厳密な管理

環境ごとのブランチ管理が必要な場合は不便

例：staging や production を分けたいケース
→ この場合は GitLab Flow や Git Flow の方が適することもある

まとめ

Github Flowは

  • シンプル
  • 学習コストが低い
  • 小～中規模チームに最適
  • アジャイルや高速リリースと相性が良い
    という扱いやすいブランチ戦略です。
    はじめてチーム開発を行う場合でも導入しやすく、コード品質の維持やコミュニケーション改善にもつながります。

Discussion