【Git基礎】主要なブランチモデルの比較

目次

各モデルの比較表

以下に GitHub Flow / Git Flow / GitLab Flow の比較表を整理しました。

項目GitHub FlowGitLab FlowGit Flow
特徴最小限の構成。main +短命ブランチのみGitHubFlowの拡張版。
GitHubFlow+環境ブランチ。
安定性重視のモデル。
長期ブランチを複数維持
ブランチ構成main
feature/*
main
feature/*
production
pre-production
・その他、必要に応じて追加
 ( 例 : staging, hotfix/* など)
main
develop
feature/*
release/*
hotfix/*
リリース管理リリースタグで対応環境別ブランチで管理
pre-productionproduction
release/* ブランチで管理
メリット・シンプルで学習コストが低い
・CI/CDとの相性が良い
・運用環境に対応した管理
・GitHubFlowと比べて、バージョン管理やリリース前検証などに対応しやすい
・ブランチで明確に役割分担が可能
・昔から利用されているため、情報が多い
デメリット・複雑なリリース管理はやや苦手
・リリース前検証環境などの扱いが難しい
・これをベースにカスタムされることが多いため、情報が標準化されていない
(=チームごとに運用がブレやすい)
・運用が複雑で学習コスト高
・ブランチの扱いが独特なため、別モデルへの移行がやや難しい
適性・Webサービス
・個人や短期間開発
・各種アプリケーション開発
・複数環境での運用が必要な場合
・中~長期間の開発
・パッケージ製品開発
・複数バージョン保守
・大規模なチーム開発

各モデルの特徴と所感

以下には、各モデルに対する個人的な所感をついてまとめます。
(個人的な見解をまとめただけのものとなりますため、あくまで参考程度にご参照ください)

GitHub-Flow

ブランチ運用における最小構成にあたるモデルだと思います。
とにかくシンプルで覚えることも少ないので、初心者でもとっつきやすいです。
一方で、運用上で「例外」にあたる状況が発生したときは少し迷いやすいかもしれません。(特殊な環境用の対応や緊急修正を含む複雑なバージョン管理等)

ざっくりいうと、シンプルな分「(仮)」的な対応が苦手なモデルで、そのような作業が多発する場合はGitLab-Flowやカスタムになる印象です。

GitLab-Flow

GitHub-Flowの拡張版。(イメージとしてはGitHub-FlowとGit-Flowの間になると思います)
mainは開発用の統合担当となり、本番環境を含め各環境をブランチとして追加する形式をとります。

GitHub-Flowは、main = 本番である性質上、以下のような環境分離が必要になる場合はGitLab-Flowを検討します。

  • リリース前テスト用の環境を設けたい
  • 社内/社外,プラットフォームなど、配布先によって環境を分けたい
  • その他、審査対応やパッケージ化作業用などで環境を作っておきたい

環境ごとにブランチを追加する性質上、基本形のまま使われるというよりは、各開発環境ごとにカスタマイズして使われるため、各ブランチの定義や運用ルールについてはある程度整備が必要になります。

Git-Flow

誤解を恐れずに言うと、教科書的なブランチモデルに相当すると思います。
役割毎にブランチを用意するため、大規模開発での分業には強みがあります。
その一方で、mainブランチがリリース用である(最もマージの発生する開発用でない)事や、永続的に存在するブランチの多さから、誤操作のリスクを含む管理コストの高さが懸念点としてよく上げられます。

古参なモデルだけあって、会社などで見かける機会はまだ多い印象です。
昨今の開発形態の変化もあって、(特にWeb系では)色々とミスマッチも指摘されますが、個人的には「絶対に使用を避ける」というほどではないと思っています。
少し癖はあるものの、「情報が標準化されている」、「役割が明確なブランチ」という長所はあるため、メンバーの習熟度や開発フローを踏まえて採用することは悪くないと思います。

モデルの選び方

個人的には、

「まずはGitHubFlowで開始し、不足があればGitLabFlow (またはカスタムモデル) へ拡張」 という形式がおすすめです。

※Git-Flowについては導入済みプロジェクトで継続運用する場合など、何らかの理由がある場合に採用を検討します。

まとめると、以下のようになります。
・GitHubFlow:下記のような要件が無く、簡潔なモデルを採用したい場合
・GitLabFlow:GitHubFlowでは不足する環境ごとの分離が必要な場合
・GitFlow:大規模な開発やすでに採用されているプロジェクトで継続使用する場合


おすすめの本:

おすすめの本:


ここまでお読みいただき、ありがとうございます。
今回紹介した内容が、皆さんの開発のヒントになれば幸いです。

記事が役に立ったと感じていただけましたら、OFUSE にてご支援いただけますと今後の運営の励みになります。

OFUSEで応援を送る

今後もゲーム制作に関するさまざまな情報や、そこから得られた知見を共有していく予定ですので、引き続き当ブログをよろしくお願いいたします。

  • URLをコピーしました!
目次