2026.11.12 開発

GitLab Flowとは：環境ブランチの組み方とGit Flow・GitHub Flowとの違い【2026年11月】

GitLab Flowは、mainへ機能ブランチをマージする単純な流れを土台に、本番用のproductionブランチや検証環境ごとのブランチ、版ごとのリリースブランチを必要な分だけ足すブランチ運用です。この記事では、GitLab Flowとは何かを公式資料で確かめたうえで、Git Flow・GitHub Flowとの違いを比較表で整理します。後半はGitLabのBranch rules、.gitlab-ci.ymlのrules、cherry-pickを使った実装例と、採用・見送りの判断が解説の対象です。画面名は2026年11月時点の公式ドキュメントにもとづいています。

まとめ：GitLab Flowはmainを起点に本番待ちのブランチを足す運用

GitLab Flowの芯は「全員がmainから切り、mainへ戻す」ことです。そのうえで、マージした瞬間に本番へ出せない事情があるときだけ、productionブランチ、環境ブランチ、リリースブランチのいずれかを足します。Git Flowのようにdevelopを常設せず、GitHub Flowのように「マージ＝デプロイ」と決め打ちもしない中間の方式です。

実装で効くのは3点です。環境ブランチへの直接pushを保護ルールで止めること、CIのrulesでブランチごとにデプロイ先を固定すること、修正は必ずmainへ先に入れてから下流へcherry-pickすること（upstream first）。検証環境が1つで承認待ちも無いなら、GitLab Flowの追加ブランチは不要で、GitHub Flow相当の運用で足ります。

GitLab Flowとは：mainを起点に本番・環境・リリースのブランチを足す運用

GitLab Flowの定義：GitHub Flowに本番待ちの置き場を足した方式

GitLabのトピックページ「GitLab Flowとは」は、GitLab FlowをGitFlowを単純にした方式と位置づけ、すべての機能と修正をmainへ入れたうえでproductionブランチとstableブランチを持つ形と説明しています。本番前のブランチは必要な数だけ足せるとされ、例としてmain→test→acceptance→productionの順が挙がっています。

同ページは、公開APIのv1・v2を別々のブランチで保守する使い方も示しています。GitLab Flowは決まった1枚の図ではなく、「mainが唯一の合流点」という原則に、デプロイの待ちや版の保守に応じた部品を足す考え方です。もう1つの柱がIssueとの結び付けで、変更は目的を書いたIssueから始め、mainから切った機能ブランチをマージリクエスト（MR）で戻します。GitLab自体の構成はGitLabの構成要素とCE・EEの違いで整理しています。

公式ドキュメントから消えた経緯と2026年11月時点で読める一次資料

GitLab Flowを調べると、古い解説記事のリンク先が見つからないことがあります。2026年11月12日時点で、docs.gitlab.comの旧URL（/ee/topics/gitlab_flow/）が返すのは404です。2023年7月のMR「Redact GitLab Flow page, create a redirect」には、GitLab Flowの説明はドキュメントではなくブログ記事で扱う方針になったと書かれています。

いまGitLab Flowの全体像を原文で読めるのは、版ごとのアーカイブに残るGitLab 16.1のドキュメント「Introduction to Git workflows」です。productionブランチ・環境ブランチ・リリースブランチの3つの型、upstream first、Issueの自動クローズまで1ページにまとまっています。現行ドキュメントではBranching strategiesのページが、GitLab Flowという名前を使わずに「Webサービス向け」「長期リリースブランチ」「環境ごとのブランチ」の3構成を紹介しています。

2014年9月29日付の初出ブログのURLも、現在はトピックページへ301で転送されます。仕様書のような正本が無い運用パターンなので、解説記事ごとにブランチ名や流れが違っていても不思議はありません。

Git Flow・GitHub Flowとの違い：長命ブランチの本数とデプロイの起点で比較

3方式の比較表：長命ブランチ・リリースの起点・hotfixの入れ方

3方式の違いは、ずっと残す長命ブランチが何本あるかと、どのブランチの状態が本番に出るかで見ると整理しやすくなります。Git Flowは2010年の原典記事、GitHub FlowはGitHubのドキュメント「GitHub flow」、GitLab Flowは前出の旧版ドキュメントの記述にもとづいています。

観点	Git Flow	GitHub Flow	GitLab Flow
長命ブランチ	mainとdevelop	mainのみ	mainと環境・版
機能ブランチの起点	develop	main	main
本番に出る状態	mainのタグ	マージ後のmain	productionの先端
hotfixの入れ方	hotfixブランチ	通常の機能ブランチ	mainへ入れ下流へ
リリース待ちの表現	releaseブランチ	表現しない	環境ブランチ

GitHub Flowの手順は「ブランチ作成→変更→プルリクエスト→レビュー対応→マージ→ブランチ削除」の6段で、リリースの待ちを置く場所がありません。GitLab Flowが足すのはまさにこの待ちの置き場です。Git Flowとの差は、待ちをdevelopとreleaseという開発側のブランチで表すか、productionや環境ブランチというデプロイ先側のブランチで表すかにあります。

developブランチを置かない理由とGit Flowからの移行で消える手順

旧版ドキュメントは、Git Flowの問題点として、開発者がツールの既定ブランチであるmainではなくdevelopを使うことになる点と、hotfixとreleaseの手順が継続的デリバリーには過剰でマージ漏れを招く点を挙げていました。developへ入れた修正をmainへ戻し忘れる、あるいはその逆、という事故です。

Git FlowからGitLab Flowへ移すと、feature→develop→release→mainという多段のマージが、feature→main→productionの一方向に変わります。消えるのはdevelopとreleaseの2種類で、hotfixブランチも「mainから切る普通の機能ブランチ」に含める運用です。Git Flow側の各ブランチの役割はfeatureブランチとdevelopブランチの意味（Git Flow）で解説しています。

原典の著者も2020年3月5日の追記で、継続的にデリバリーするWebアプリにはGitHub Flowのような単純な方式を勧めました。GitLab Flowはその間で、検証や承認の待ちがあるWebアプリを受け持つ方式と捉えると選びやすくなります。

GitLab Flowの3つの型：production型・環境型・リリース型のブランチ構成

productionブランチ型：マージとデプロイの時刻を切り離す最小構成

最小の構成は、mainに加えてproductionブランチを1本持つ形です。旧版ドキュメントは、マージのたびに本番へ出せない例として、App Storeの審査を通った時点で公開されるiOSアプリや、デプロイしてよい時間帯が決まっている運用を挙げています。mainをproductionへマージした時点が本番反映で、本番に何が入っているかはproductionブランチを見れば分かります。

マージコミットの時刻はおおよそのデプロイ時刻を示しますが、正確な時刻が要るならデプロイのたびにタグを打つ方法も示されています。GitLabのベストプラクティスのページも「デプロイはブランチかタグで自動化する」「タグは人が打ち、CIに打たせない」としており、productionへのマージを合図にCIがデプロイする構成が基本になります。

環境型：main→pre-production→productionへ下流一方向にマージ

検証環境が複数あるなら、環境ごとにブランチを対応させます。旧版ドキュメントの例では、stagingはmainから自動で更新し、pre-productionへはmainからのMRで、productionへはpre-productionからのMRで反映します。変更は上流から下流へ一方向にしか流れないため、本番に届いたコードはすべての環境を通過済みになる、というのがこの型の保証です。

ブランチ名はチームの環境名に合わせてかまいません。ただし本数は環境の数と一致させ、環境に対応しない長命ブランチを増やさないことが条件です。現行のBranching strategiesも、環境ごとのブランチは別チームが相互依存するサービスを開発する組織や、ウォーターフォール・V字モデルの開発で使われるとし、長命ブランチは契約上の必要がない限り避けるよう書いています。

リリースブランチ型：2-3-stableの切り方とupstream firstの修正手順

利用者へ版を配る製品では、マイナー版ごとにリリースブランチを切ります。本記事の例では2-3-stableのような名前にします。旧版ドキュメントの指針は、mainから切ること、切る時期はできるだけ遅くすること、切った後は重大なバグ修正だけを入れること、修正を入れるたびにパッチ版を上げることの4つです。

修正は先にmainへマージし、その後でリリースブランチへcherry-pickします。これがupstream firstです。逆順にすると、2.3系では直ったのに次の2.4系で同じバグが再発する、という事故が起きます。GitLabのベストプラクティスのページも「バグはmainで先に直し、リリースブランチは2番目」と書いています。切ったリリースブランチからリリースを作る手順はGitLab Releaseの作り方：CIのreleaseキーワードとglabで自動作成する手順にまとめています。

GitLabで環境ブランチを実装する手順：保護・CI・Issue連携の設定例

Branch rulesとAPIで環境ブランチへの直接pushを止める設定

環境ブランチ型が崩れる最初のきっかけは、productionへの直接pushです。現行の保護ブランチのドキュメントでは、設定場所がSettings > Repository > Branch rulesに変わっています。ルールを作ると「Allowed to push and merge」の初期値がMaintainersなので、直接pushを禁じる場合に指定する値はNo oneです。ブランチ名と*のワイルドカードは大文字小文字を区別する点にも注意します。

複数のプロジェクトへ同じ設定を配るなら、Protected branches APIのほうが確実です。アクセスレベルは0（No access）、30（Developer）、40（Maintainer）の数値で指定します。

# production と *-stable を「push 不可・マージは Maintainer のみ」で保護する
# PROJECT_ID と GITLAB_TOKEN（api スコープ）は事前に設定しておく
for BR in production "*-stable"; do
  curl --request POST \
    --header "PRIVATE-TOKEN: ${GITLAB_TOKEN}" \
    --data-urlencode "name=${BR}" \
    --data "push_access_level=0" \
    --data "merge_access_level=40" \
    --data "allow_force_push=false" \
    "https://gitlab.example.com/api/v4/projects/${PROJECT_ID}/protected_branches"
done

基本の保護ブランチはFreeから使えます。一方、Code Ownerの承認必須化はPremium・Ultimate限定です。既定ブランチのmainは最初から保護されているため、追加するのはproductionや環境ブランチ、リリースブランチの分になります。

.gitlab-ci.ymlのrulesでブランチごとにデプロイ先を切り替える例

次は「どのブランチの更新がどの環境へ出るか」をCIで固定します。定義済み変数のCI_COMMIT_BRANCHはブランチのパイプラインで使え、MRパイプラインやタグのパイプラインでは使えません。環境ブランチへのマージ後に走るパイプラインで判定するのに向いています。

stages:
  - test
  - deploy

test:
  stage: test
  script:
    - make test

deploy_staging:
  stage: deploy
  script:
    - ./deploy.sh staging
  environment:
    name: staging
    url: https://staging.example.com
  resource_group: staging
  rules:
    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH   # main への反映で staging を更新

deploy_production:
  stage: deploy
  script:
    - ./deploy.sh production
  environment:
    name: production
    url: https://www.example.com
    deployment_tier: production
  resource_group: production
  rules:
    - if: $CI_COMMIT_BRANCH == "production"          # production への反映だけで本番へ出す

environmentを書くと、Operate > Environmentsにデプロイ履歴が残り、過去のデプロイを選んで戻せます。deployment_tierの値はdevelopment・testing・staging・production・otherの5種です。resource_groupは同じ環境へのデプロイを1本ずつに絞る指定で、既定の処理順はunorderedになります。ジョブを実際に動かすRunnerの用意はGitLab Runnerのexecutorの選び方と登録手順を参照してください。rulesの評価順やworkflow:rulesで二重パイプラインを防ぐ書き方はGitLab CI/CDの.gitlab-ci.ymlの書き方とrules・needs・変数の設定例にまとめています。

昇格用マージリクエストとcherry-pickでhotfixを下流へ流す操作

mainからproductionへの昇格は、ソースmain・ターゲットproductionのMRを作ってマージします。MRにすると、本番へ入る差分の一覧と承認の記録が残ります。MRの作り方そのものはGitLabの使い方（プロジェクト作成からIssue・MR・CI/CDまで）の手順と同じです。昇格用MRに承認ルールやマージ条件を掛ける設定はGitLabのマージリクエスト：作成から承認ルール・マージ方式の設定までで扱っています。

hotfixは機能ブランチをmainへマージした後、下流へ持っていきます。GitLabのcherry-pickのドキュメントでは、マージ済みMRの「Merged by」欄にあるCherry-pickから取り込み先のブランチを選び、「Start a new merge request with these changes」を選ぶと新しいMRとして作れます。マージコミットをcherry-pickすると元のMRにシステムノートが付き、どの版へ入れたかを後から追跡できる仕組みです。

# CLI で行う場合：main に入った修正を 2-3-stable へ取り込む
git fetch origin
git switch -c hotfix-2-3-login origin/2-3-stable
git cherry-pick -x a1b2c3d          # -x で元コミットの SHA をメッセージに残す
git push -u origin hotfix-2-3-login  # この後 2-3-stable 宛ての MR を作る

CLIで行ったcherry-pickにはシステムノートが付かないため、-xで元のSHAを残しておくと追跡が楽になります。fast-forwardマージを選んだプロジェクトでは、UIからcherry-pickできるのがsquash済みのMRか単一コミットのMRに限られる点にも注意が要ります。

Closes #でIssueを閉じる条件とマージ方法の設定の合わせ方

MRの説明にCloses #4のように書くと、Issueの自動クローズが働きます。使えるキーワードはClose・Fix・Resolve・Implementとその語形変化です。閉じるのは既定ブランチへマージまたはpushされたときだけなので、GitLab Flowではmainへのマージ時点でIssueが閉じ、productionやリリースブランチへの反映では閉じません。

「本番に出たら閉じたい」なら、ラベルなど自動クローズとは別の目印を使います。マージ方法はSettings > Merge requestsでMerge commit（既定）、semi-linear、Fast-forwardの3種から選べます。昇格MRの記録を残す環境ブランチ型では、マージコミットが残る既定のままが扱いやすい設定です。push済みブランチを書き換える危険はgit rebaseとmergeの違いで整理しています。

GitLab Flowを採用する条件と見送る場面：チーム構成とリリース頻度で判断

採用してよい条件：検証環境での承認待ちやリリース時刻の制約がある場合

GitLab Flowの追加ブランチを置いてよいのは、mainへのマージと本番反映の間に「待ち」があるチームです。具体的には、顧客の受け入れ検証環境で承認を取ってから本番へ出す受託開発、夜間など決まった時間帯にしかデプロイできない業務システム、ストア審査を挟むモバイルアプリ、v1とv2を並行保守するAPIの4つが典型です。

待ちが「承認」だけなら、環境ブランチを増やす前に環境側の機能で足りないかを確かめます。GitLabの保護環境はPremium・Ultimateで使え、デプロイできるロールや承認者を環境単位で指定できる機能です。GitHubで同じことをする場合の設計はGitHub ActionsのEnvironmentsの承認ゲートが参考になります。

見送るべき場面：環境ブランチが乱立し差分が戻らなくなる失敗パターン

見送るべきなのは、検証環境が1つで承認も不要、マージしたら即デプロイしてよいチームです。この場合productionブランチは手順を1段増やすだけなので、GitHub Flow相当の運用にとどめます。

導入後の典型的な失敗は2つあります。1つ目は、本番障害の修正をproductionへ直接入れてmainへ戻し忘れることです。次の昇格MRで修正が消え、同じ障害が再発します。2つ目は、顧客ごと・機能ごとに長命ブランチを足し、環境と対応しないブランチ同士で差分が戻らなくなることです。どちらも、環境ブランチへの直接pushを保護ルールで禁止し、修正は必ずmainから流す、という2つの規則を最初に機械で強制しておけば防げます。

ブランチ運用をCIや承認フローまで含めて設計し直したい、既存のGit Flowから移行したいといった場合は、一創のDevOps・CI/CD導入支援で、現状の環境構成とリリース手順を確認したうえで移行計画を作成できます。方式の選び方そのものを4方式で比べたい場合はGit運用のベストプラクティス（ブランチ戦略の選定基準）が入口になります。

よくある質問

GitLab Flowについて、導入前によく出る質問をまとめました。

GitLab FlowはGitLabでしか使えませんか？

GitLab以外でも使えます。GitLab Flowはブランチの運用ルールなので、GitHubやBitbucketでも同じ構成を組めます。ただし本記事で示した保護ルール、CI_COMMIT_BRANCHを使うrules、MRからのcherry-pick、Closes #での自動クローズはGitLabの機能です。GitHubなら保護ブランチのルールとGitHub ActionsのEnvironments、プルリクエストのキーワードによるIssueクローズで置き換えることになります。サービスごとの機能差はGitHubとGitLabの比較記事が参考になります。

GitLab Flowでdevelopブランチは使いますか？

使いません。機能ブランチはmainから切ってmainへ戻すのが原則で、「次の版を集める長命ブランチ」は置かない方式です。検証用の置き場が欲しい場合は、developではなくstagingやpre-productionのように環境の名前でブランチを作ります。名前を環境に合わせると、どのブランチがどこへデプロイされるかをCIの設定と1対1で対応させられます。

環境ブランチとリリースブランチはどう使い分けますか？

環境ブランチは「どの環境に何が出ているか」を表し、Webサービスのように本番が1つしかない場合に使います。リリースブランチは「どの版に何が入っているか」を表し、利用者の手元に複数の版が残るパッケージ製品やAPIが使用対象です。両方を同時に持つと長命ブランチが掛け算で増えるため、まずどちらか一方で足りないかを確かめます。版を配らないWebサービスで-stableブランチを作る必要はありません。

GitLab Flowの公式ドキュメントはどこで読めますか？

2026年11月時点で、現行のdocs.gitlab.comにGitLab Flowの専用ページはありません。全体像はGitLab 16.1のドキュメントのアーカイブ「Introduction to Git workflows」で読めます。概要だけならabout.gitlab.comのトピックページ「What is GitLab Flow?」が日本語でも公開されています。

GitLab Flowでhotfixはどう入れればよいですか？

hotfixもmainから機能ブランチを切り、mainへのMRとして先にマージします。そのあとproductionやリリースブランチへ流す手段は、cherry-pickかMRです。急ぐ場面でもproductionへ直接入れると、次にmainを昇格したとき修正が消えてしまいます。直接pushを保護ルールで禁じておくのが確実な歯止めです。