← ガイド一覧に戻る

Gitワークフローガイド - Git Flow vs GitHub Flow vs GitLab Flow 2025年版

GitワークフローGit FlowGitHub FlowGitLab Flowブランチ戦略チーム開発2025年

ガイド

Gitワークフローガイド - Git Flow vs GitHub Flow vs GitLab Flow 2025年版

概要

Gitワークフローは、チーム開発において一貫性のあるブランチ戦略と開発プロセスを確立するための重要な手法です。2025年現在、Git Flow、GitHub Flow、GitLab Flowという3つの主要なワークフローが広く採用されています。

本ガイドでは、各ワークフローの特徴、メリット・デメリット、実装方法を詳しく解説し、プロジェクトに最適なワークフロー選定の指針を提供します。また、Conventional Commitsやコミットリントツールを活用した最新のベストプラクティスも紹介します。

詳細

Git Flow（ギットフロー）

Git Flowは2010年にVincent Driessenによって提案された、構造化されたブランチ戦略です。複雑なプロジェクトやリリースサイクルが明確なプロジェクトに適しています。

主要ブランチ

  • main（master） - 本番リリース用の安定版ブランチ
  • develop - 開発の統合ブランチ

サポートブランチ

  • feature/ - 新機能開発用
  • release/ - リリース準備用
  • hotfix/ - 緊急修正用

特徴

  • 構造化されたリリース管理
  • 複数バージョンの並行管理が可能
  • 明確な役割分担とプロセス

GitHub Flow（ギットハブフロー）

GitHub Flowは、シンプルさと継続的デプロイメントに焦点を当てた軽量なワークフローです。

基本原則

  1. mainブランチは常にデプロイ可能
  2. 機能開発は記述的な名前のブランチで行う
  3. 定期的にリモートにプッシュする
  4. プルリクエストでフィードバックを求める
  5. レビュー後にmainにマージ
  6. マージ後は即座にデプロイ

特徴

  • シンプルで理解しやすい
  • 継続的デプロイメントに最適
  • 小規模チームに適している

GitLab Flow（ギットラボフロー）

GitLab Flowは、GitHub Flowの柔軟性とGit Flowの構造を組み合わせたハイブリッドアプローチです。

環境ブランチ戦略

  • main - 開発の中心ブランチ
  • pre-production - ステージング環境
  • production - 本番環境

特徴

  • 環境別ブランチによる段階的リリース
  • GitHub Flowよりも構造化されている
  • CI/CDパイプラインとの統合が容易

2025年のベストプラクティス

トランクベース開発への移行

現代の開発チームは、よりシンプルなトランクベース開発を採用する傾向にあります。これはGitHub FlowやGitLab Flowの原則に近く、以下の利点があります：

  • 継続的インテグレーションが容易
  • マージコンフリクトの削減
  • フィードバックサイクルの短縮

Conventional Commitsの採用

標準化されたコミットメッセージフォーマットを使用することで、自動化ツールとの連携が可能になります。

推奨ツール

  • Commitizen - 対話的なコミットメッセージ作成
  • Commitlint - コミットメッセージの検証
  • Husky - Gitフックの管理
  • semantic-release - 自動バージョニングとリリース

メリット・デメリット

Git Flow

メリット

  • 明確な構造とルール
  • 複数バージョンの管理が容易
  • 大規模プロジェクトに適している
  • リリースサイクルが予測可能

デメリット

  • 複雑で学習コストが高い
  • CI/CDとの相性が悪い
  • オーバーヘッドが大きい
  • モダンな開発手法との不整合

GitHub Flow

メリット

  • シンプルで理解しやすい
  • 継続的デプロイメントに最適
  • 高速なフィードバックサイクル
  • 小規模チームに適している

デメリット

  • 本番環境でのバグリスクが高い
  • 複数バージョンの管理が困難
  • リリースの制御が限定的

GitLab Flow

メリット

  • 柔軟性と構造のバランス
  • 環境別の管理が容易
  • CI/CDとの統合が良好
  • あらゆる規模のチームに対応

デメリット

  • GitHub Flowより複雑
  • 環境ブランチの管理が必要
  • 初期設定に時間がかかる

参考ページ

書き方の例

Git Flow実装例

# 1. プロジェクトの初期化
git flow init

# 2. 新機能の開発開始
git flow feature start new-feature

# 3. 機能開発とコミット
git add .
git commit -m "feat: 新しい検索機能を追加"

# 4. 機能をdevelopにマージ
git flow feature finish new-feature

# 5. リリースの準備
git flow release start 1.0.0

# 6. リリース完了
git flow release finish 1.0.0

# 7. 緊急修正
git flow hotfix start critical-fix
# 修正作業
git flow hotfix finish critical-fix

GitHub Flow実装例

# 1. mainブランチから新しいブランチを作成
git checkout -b feature/add-user-authentication

# 2. 変更を加えてコミット
git add .
git commit -m "feat: ユーザー認証機能を追加"

# 3. 定期的にリモートにプッシュ
git push origin feature/add-user-authentication

# 4. プルリクエストを作成（GitHub UI経由）
# またはCLI使用
gh pr create --title "ユーザー認証機能の追加" \
  --body "JWTベースの認証システムを実装しました"

# 5. レビュー後にmainにマージ
git checkout main
git pull origin main
git merge --no-ff feature/add-user-authentication

# 6. 即座にデプロイ
npm run deploy

GitLab Flow実装例

# 1. mainから機能ブランチを作成
git checkout -b feature/payment-integration main

# 2. 開発とコミット
git add .
git commit -m "feat: 決済システムとの統合"

# 3. mainにマージ
git checkout main
git merge --no-ff feature/payment-integration

# 4. pre-productionへのマージ（テスト環境）
git checkout pre-production
git merge --no-ff main

# 5. productionへのマージ（本番環境）
git checkout production
git merge --no-ff pre-production
git tag v2.1.0

Conventional Commitsの例

# 機能追加
git commit -m "feat(auth): JWTトークン検証を実装"

# バグ修正
git commit -m "fix(api): ユーザー削除時のエラーを修正"

# ドキュメント更新
git commit -m "docs: APIエンドポイントのドキュメントを更新"

# パフォーマンス改善
git commit -m "perf(db): クエリの最適化によりレスポンス時間を50%短縮"

# 破壊的変更
git commit -m "feat(api)!: APIレスポンス形式を変更

BREAKING CHANGE: レスポンスのdata配列がresultsに変更されました"

# スコープ付きリファクタリング
git commit -m "refactor(components): ボタンコンポーネントを再構築"

Commitizenを使った対話的コミット

# Commitizenのインストール
npm install --save-dev commitizen cz-conventional-changelog

# package.jsonに設定追加
{
  "scripts": {
    "commit": "cz"
  },
  "config": {
    "commitizen": {
      "path": "cz-conventional-changelog"
    }
  }
}

# 対話的コミットの実行
npm run commit
# ? Select the type of change that you're committing: feat
# ? What is the scope of this change: auth
# ? Write a short description: implement JWT validation
# ? Provide a longer description: (optional)
# ? Are there any breaking changes? No
# ? Does this change affect any open issues? No

Commitlintとhuskyの設定

# 必要なパッケージのインストール
npm install --save-dev @commitlint/{cli,config-conventional} husky

# commitlint設定ファイルの作成
echo "module.exports = {extends: ['@commitlint/config-conventional']}" > commitlint.config.js

# huskyの初期化
npx husky init

# commit-msgフックの作成
echo "npx --no -- commitlint --edit \$1" > .husky/commit-msg

# 使用例（不正なコミットメッセージ）
git commit -m "added stuff"
# ✖ subject may not be empty [subject-empty]
# ✖ type may not be empty [type-empty]

# 正しいコミットメッセージ
git commit -m "feat: ログイン機能を追加"
# ✔ Commit message follows conventional commits

チーム開発でのブランチ戦略

# プロジェクト初期設定
git init
git remote add origin https://github.com/team/project.git

# ブランチ保護ルールの設定（GitHub CLI使用）
gh repo edit --enable-auto-merge --delete-branch-on-merge

# チームメンバーの作業フロー
# 1. 最新のmainを取得
git checkout main
git pull origin main

# 2. 作業ブランチの作成（チケット番号を含める）
git checkout -b feature/PROJ-123-add-search-functionality

# 3. 定期的なコミット（Conventional Commits準拠）
git add src/search/*
git commit -m "feat(search): 基本的な検索ロジックを実装"

git add tests/search/*
git commit -m "test(search): 検索機能のユニットテストを追加"

# 4. リベースでmainの最新変更を取り込む
git fetch origin
git rebase origin/main

# 5. プッシュとプルリクエスト作成
git push -u origin feature/PROJ-123-add-search-functionality
gh pr create --assignee @me --label enhancement

# 6. レビュー対応
git commit -m "refactor(search): レビューコメントに基づいて検索アルゴリズムを改善"
git push

# 7. スカッシュマージ（履歴をクリーンに保つ）
gh pr merge --squash --delete-branch