【Git基礎】GitLab-Flowの概要と基本作業手順

2025年12月7日

この記事で分かること

GitLab-Flow の概要
代表的なブランチ（main/production/pre-production/feature など）の役割
それぞれの作業ごとの代表的なコマンド手順

GitLab-Flow の概要

GitLab-Flow は、Gitのにおける代表的なブランチ運用モデルの一種です。
シンプルな構成を保ちつつ、環境ベースのブランチを用意することが特徴で、様々な開発・運用に対応できます。

各ブランチの役割一覧

GitLab-Flowで使用するブランチとその役割は以下の通りです。
（あくまで基本形のため、ほとんどの場合以下をベースにカスタムされます）

ブランチ名	役割
main	・名前の通り、主となるブランチ・開発の統合はここで実施し、常に最新の安定状態を維持する。・`pre-production` 宛でマージリクエスト
pre-production	・本番前の検証環境用ブランチ（≒ステージング環境）・`main` からマージされ、主にリリース前のテストを行う・開発チームだけでなく、QAチームなども確認する場所・テスト承認後、`production` 宛でマージリクエスト
production	・本番環境（リリース）用ブランチ・`pre-production` からマージされ、実際にリリースを実施。
feature/*	・開発機能ごとのブランチ・`main` から派生し、完了後 `main` にマージリクエストし、削除
fix/*	・通常時(pre-productionテストで発見)の不具合修正ブランチ・`main` から派生し、完了後 `main` にマージリクエストし、削除・featureにまとめて、コミットメッセージで区別する運用も可
hotfix/*	・リリース後の緊急修正用ブランチ・`production` から派生し、修正後は各環境へ統合

運用時のポイント(ルール例)

開発作業は必ず feature ブランチで実施
マージは、main -> pre-production -> production と段階的に実施
( production -> pre-production といった逆方向へのマージは禁止)
永続ブランチ（main / pre-production / production）は 直接 push 禁止 → PR/MR 経由で統合
feature は小まめに main にマージし、大きな差分をためない
pre-production は必ず受け入れテストを経由してから production にマージ
hotfix は production 起点 で作業し、必ず main / pre-production に同期
（コンフリクトが出た場合は基本的にhotfix優先：本番安定のため）

推奨されるタグ運用ルール例

形式: v<major>.<minor>.<patch>
- major : 互換性を壊す変更（例: v2.0.0）
- minor : 機能追加（例: v1.3.0）
- patch : バグ修正・hotfix（例: v1.2.1, v1.2.2）
付与のタイミング
- productionの PR 承認 & マージ後
  →production に反映された時点で必ず付与（リリース時/hotfix適用時）
タグは必ず production に付与
- main / pre-production ではタグを打たないこと
メッセージ例

git tag -a v1.3.0 -m "Release v1.3.0: Add new feature A and improve B"
git tag -a v1.2.2 -m "Hotfix release v1.2.2: Fix urgent issue in payment API"

命名ルール

ブランチ命名規則（推奨）

issue番号 を付けると追跡しやすい（Jira, GitHub Issuesなどと紐付け）
英語スネークケースやケバブケースを使い、スペースや日本語は避ける
hotfix は緊急性が高いので issue番号なし でも OK

種類	命名規則	例
Feature	`feature/<issue番号>-<概要>`	`feature/123-add-login-api`
Bugfix	`fix/<issue番号>-<概要>`	`fix/234-fix-timezone-bug`
Hotfix	`hotfix/<概要>`	`hotfix-fix-critical-crash`
Release Test	`pre-production`（固定）	–
Production	`production`（固定）	–
Main	`main`（固定）	–

📝 コミットメッセージ規約（推奨）

基本的には Conventional Commits に準拠するのがおすすめです。

<type>(<scope>): <短い説明>
<空行>
<詳細な説明（必要な場合）>
<空行>
Refs: #<issue番号>

type の例

feat: 新機能追加
fix: バグ修正
hotfix: 緊急修正（production 直結）
docs: ドキュメント変更
style: コードスタイル修正（動作に影響なし）
refactor: リファクタリング
test: テスト追加・修正
chore: ツール・設定・ビルド関連

記述例：

feat(auth): add JWT login API

Implement JWT-based authentication with refresh tokens.
Refs: #123

fix(timezone): correct UTC+9 conversion in scheduler

The job scheduler was incorrectly handling daylight saving times.
Refs: #234

hotfix(payment): fix critical bug in payment API

Rollback transaction issue caused production outage.
Refs: #789

タグ命名規則（再掲）

形式: v<major>.<minor>.<patch>
例: v1.3.0, v1.2.2
原則として production にのみ付与
リリースノートは GitHub/GitLab の Release 機能を併用する

プロジェクト作成時の準備

新規リポジトリの作成

git init

初回コミット

# ファイル作成
echo "# My New Project" > README.md

# ステージング & コミット
git add README.md
git commit -m "Initial commit"

ブランチ名の確認：出力が*main となっていればOK

git branch

ブランチのリネーム対応方法

* main となっていなければ、以下コマンドでリネーム

# ブランチ名が main となっていないの場合のみ実行
git branch -m master main

# (必要なら)デフォルトの開始時ブランチ名を再設定
git config --global init.defaultBranch main

リモートリポジトリの作成 (GitHub)
Web UI から作成：GitHub → [New Repository]
※「Initialize with README」はチェックしない（作成済みのため）
リモートリポジトリの登録とプッシュ

git remote add origin git@github.com:username/my-new-project.git
git push -u origin main

環境ブランチ( pre-production , production )作成

# main から pre-production 作成
git checkout -b pre-production main

# pre-production から production 作成
git checkout -b production pre-production

# 確認
git branch
  main
  pre-production
* production

リモートに環境ブランチをプッシュ

# pre-production へチェックアウトし、プッシュ
git checkout pre-production
git push -u origin pre-production

# pre-production へチェックアウトし、プッシュ
git checkout production
git push -u origin production

# main へ復帰
git checkout main

GitHub のブランチ保護設定
- GitHub → Repository → [Settings] > [Branches]
- Branch protection rules を設定
  - main / pre-production / production を対象
  - 直接 push 禁止
  - PR レビュー必須
  - CI 成功必須

開発時のワークフロー

以下に、 pre-production → production リリース前提 で整理した、GitHub（またはローカル Git）を想定した各作業時の手順をまとめます。

新機能開発（feature）

開発者は main から feature/* を切って作業します。

# main を最新化(リモート→ローカル)
git checkout main
git pull origin main

# feature ブランチ作成
git checkout -b feature/awesome-feature

# 開発作業
# 例: ファイル作成・修正
git add .
git commit -m "Add awesome feature"

# リモートに push
git push -u origin feature/awesome-feature

# → GitHub 上で Pull Request (PR) 作成
# → レビュー & 承認後、main にマージ

pre-production への反映（リリース候補作成）

main にマージされたコードをステージング環境で検証します。

# main を最新化
git checkout main
git pull origin main

# pre-production に切り替え
git checkout pre-production
git pull origin pre-production

# main の変更をマージ
git merge main

# リモートに push
git push origin pre-production

# GitHub Actions などで pre-production 環境にデプロイ
# 受け入れテストを実施

production への反映（本番リリース）

ステージングで検証が完了したら production にマージし、本番環境にデプロイします。

# pre-production を最新化
git checkout pre-production
git pull origin pre-production

# production に切り替え
git checkout production
git pull origin production

# pre-production の変更をマージ
git merge pre-production

# リモートに push
git push origin production

# GitHub Actions などで production 環境にデプロイ
# 必要に応じてリリースタグ付与
# 例: git tag -a v1.0.0 -m "Release v1.0.0"; git push origin v1.0.0


git checkout production
git pull origin production

# バージョンタグを作成（例: v1.2.0）
git tag -a v1.2.0 -m "Release v1.2.0"
git push origin v1.2.0

緊急修正（hotfix）

本番で問題が起きた場合は、production から直接修正ブランチを切ります。

# production から hotfix ブランチ作成
git checkout production
git pull origin production
git checkout -b hotfix/urgent-fix

# 修正作業
git add .
git commit -m "Hotfix: urgent fix for issue XYZ"

# リモートに push
git push -u origin hotfix/urgent-fix

# → GitHub 上で PR を作成し、production にマージ（即デプロイ）

# タグ付与
git checkout production
git pull origin production

git tag -a v1.2.2 -m "Hotfix release v1.2.2"
git push origin v1.2.2

# 修正内容を pre-production / main にも反映
git checkout pre-production
git pull origin pre-production
git merge production
git push origin pre-production

git checkout main
git pull origin main
git merge production
git push origin main

なぜ、hotfix は production から分岐作成するか

基本的には、hotfixはmainではなくproduction から分岐作成し、その理由は以下になります。

production が今動いている本番環境の状態を表す
→ 緊急修正は必ずこの状態に直接乗せる必要がある
main と production の内容が完全に一致しているとは限らない
→main に新機能がマージされている可能性があり、その場合、main から hotfix を切ると「未リリースの変更」が一緒に入ってしまう危険
最短ルートで修正を本番反映するため
production → hotfix → production の流れなら即リリース可能

pre-productionで修正が発生したとき

pre-productionで実施するリリース前テストによって不具合が確認され、修正が発生した場合は以下のように対応します。

対応： 修正は main ブランチで行い、再度 pre-production に取り込む
（main で修正 → pre-production に再マージ → 再テスト → production）

修正用ブランチを切る：
・main を基点に修正用ブランチを作成
・ブランチ名は fix/xxx や bugfix/xxx などで管理すると分かりやすい

# main を最新化
git checkout main
git pull origin main

# 修正用ブランチ作成
git checkout -b fix/bug-issue-123

2. 修正を実装 & コミット：
　　・GitHub 上で PR を作成し、レビュー後に main にマージ

# コード修正
git add .
git commit -m "Fix bug issue #123: description of the fix"

# リモートへ push
git push -u origin fix/bug-issue-123

3. pre-production に反映 →これで修正が pre-production に反映され、再テスト可能

# pre-production を最新化
git checkout pre-production
git pull origin pre-production

# main をマージ
git merge main
git push origin pre-production

4. 再テスト後、問題なければ production へマージ

# pre-production が安定したら production へマージ
git checkout production
git pull origin production
git merge pre-production
git push origin production

# タグ付与
git tag -a v1.2.1 -m "Bugfix release v1.2.1"
git push origin v1.2.1

ポイント

修正は必ず main で行う
pre-production で直接修正してしまうと、main に反映されず将来のバージョンで再発するリスクあり
main → pre-production → production の流れを一貫させることで、修正が確実に全環境に反映される
緊急度が高ければ hotfix と同じ流れ（production 起点） もあり得るが、通常は main 起点が望ましい

不要になったブランチの削除

一時的なブランチ（feature / fix / hotfix）を削除は、以下のように行います

ローカルブランチ削除

git branch -d feature/awesome-feature
git branch -d fix/bug-issue-123
git branch -d hotfix/urgent-fix

-d は「安全削除」：マージ済みでないと削除できない
強制的に削除する場合は -D を使う（推奨はしない）

2. リモートブランチ削除

git push origin --delete feature/awesome-feature
git push origin --delete fix/bug-issue-123
git push origin --delete hotfix/urgent-fix

削除のタイミング

一時ブランチは 必ず PR マージ後に削除する
削除は GitHub/GitLab 上の UI からでも OK
（PR マージ後に「Delete branch」ボタンが出る）
定期的に不要ブランチをリポジトリから掃除してクリーンに保つ
feature / fix
→ main にマージ済みになったら削除
hotfix
→ production にマージ済み、かつ main / pre-production にも取り込み済みになったら削除

おすすめの本：

リンク

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

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

OFUSEで応援を送る

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

URLをコピーしました！