Git Flow: プロフェッショナルなブランチング ワークフロー
Git フロー 厳密な構造を定義する Git の分岐パターンです さまざまな規模のプロジェクトを管理するために設計されたブランチ。 Vincent Driessen、Git Flow によって作成されました 特に次のようなプロジェクトに適しています。 予定されているリリース そして作業チーム 複数の機能を並行して実行します。
🎯 何を学ぶか
- Git Flow のブランチ構造 (メイン、開発、機能、リリース、ホットフィックス)
- 機能、リリース、ホットフィックスを管理する方法
- 命名規則とベストプラクティス
- Git Flow と他のワークフローをいつ使用するか
主要支店
Git Flow は、プロジェクトの存続期間中存続する 2 つの永続ブランチを使用します。
メイン (またはマスター):
- コードのみが含まれます 生産の準備ができています
- 各コミットは正式リリースです
- バージョン番号のタグ付け (v1.0.0、v1.1.0 など)
- 一度もない 直接コミットする
開発する：
- の支店 統合 新機能については
- 最新の開発状況が記載されています
- 機能分岐はここから始まります
- 将来のリリースのベース
Git フローの初期化
# Inizia un nuovo progetto con Git Flow
git flow init
# O manualmente:
git checkout -b develop main機能ブランチ
I 機能ブランチ これらは新しい機能を開発するために使用されます。彼らはから始まります
develop そして再びマージされます develop 完成したら。
ワークフロー機能ブランチ
# Crea un nuovo feature branch
git flow feature start user-authentication
# Equivalente a:
# git checkout -b feature/user-authentication develop
# Lavora sulla feature
git add .
git commit -m "feat: add login form"
git commit -m "feat: add JWT authentication"
git commit -m "test: add auth tests"
# Finisci la feature (merge in develop e cancella il branch)
git flow feature finish user-authentication
# Equivalente a:
# git checkout develop
# git merge --no-ff feature/user-authentication
# git branch -d feature/user-authentication📝 機能の命名規則
feature/user-authenticationfeature/payment-integrationfeature/dark-mode- ケバブハウスを利用する
- 説明的で簡潔な名前
リリースブランチ
I リリースブランチ 本番環境での新しいリリースの準備をサポートします。
これらにより、チームの作業中にマイナーなバグ修正やメタデータの準備 (バージョン、ビルド日) が可能になります。
取り組み続ける develop.
ワークフローリリースブランチ
# Crea release branch da develop quando le feature sono pronte
git flow release start 1.2.0
# Equivalente a:
# git checkout -b release/1.2.0 develop
# Bug fix e preparazione release
git commit -m "chore: bump version to 1.2.0"
git commit -m "fix: correct typo in welcome message"
git commit -m "docs: update changelog"
# Finisci la release (merge in main E develop, tag su main)
git flow release finish 1.2.0
# Equivalente a:
# git checkout main
# git merge --no-ff release/1.2.0
# git tag -a v1.2.0
# git checkout develop
# git merge --no-ff release/1.2.0
# git branch -d release/1.2.0
# Pusha main, develop e i tag
git push origin main develop --tags⚙️ リリースブランチで行うべきこと
- ✅ マイナーなバグ修正
- ✅ バージョン番号を更新する
- ✅ 変更履歴を準備する
- ✅ 実稼働ビルドと最終テスト
- ❌ 新機能 (開発に進む)
ホットフィックスブランチ
Gli ホットフィックスブランチ 本番環境で修正できない重大なバグを修正するためです。
次のリリースを待ちます。彼らはから始まります main とマージされます main
E develop.
ワークフローホットフィックスブランチ
# Bug critico in produzione! (main è alla v1.2.0)
git flow hotfix start 1.2.1
# Equivalente a:
# git checkout -b hotfix/1.2.1 main
# Correggi il bug
git commit -m "fix: resolve critical payment bug"
# Finisci l'hotfix (merge in main e develop, tag su main)
git flow hotfix finish 1.2.1
# Equivalente a:
# git checkout main
# git merge --no-ff hotfix/1.2.1
# git tag -a v1.2.1
# git checkout develop
# git merge --no-ff hotfix/1.2.1
# git branch -d hotfix/1.2.1
# Deploy immediato in produzione
git push origin main develop --tags完全な例: 開発サイクル
機能開発から運用までの完全なワークフローを見てみましょう。
完全な Git フロー サイクル
# Setup iniziale
git flow init
# Crea branch: main, develop
# Sprint 1: Due sviluppatori lavorano su feature diverse
# Developer 1:
git flow feature start shopping-cart
# ... lavoro ...
git commit -m "feat: add cart component"
git flow feature finish shopping-cart
# Developer 2:
git flow feature start user-profile
# ... lavoro ...
git commit -m "feat: add profile page"
git flow feature finish user-profile
# Entrambe le feature sono ora in develop
# Prepara release
git flow release start 1.0.0
git commit -m "chore: bump version to 1.0.0"
git commit -m "docs: update README"
git flow release finish 1.0.0
# main ora è alla v1.0.0, deploy in produzione
# Bug critico trovato in produzione!
git flow hotfix start 1.0.1
git commit -m "fix: cart total calculation error"
git flow hotfix finish 1.0.1
# main ora è alla v1.0.1, hotfix deployato
# Nel frattempo, develop continua con nuove feature
git checkout develop
git flow feature start payment-gateway
# ... sviluppo continua ...Git Flow のベスト プラクティス
✅ やるべきこと
- アメリカ合衆国
--no-ffマージ用 (ブランチ履歴を維持) - タグ いつも メインでのリリース
- 説明的なコミット メッセージを作成する (従来のコミット)
- 機能/リリースを終了する前にテストする
- Pushaは定期的に開発とメインを行います
- 完了前にプルリクエストを使用してコードレビューを行う
❌ してはいけないこと
- メインや開発に直接コミットしないでください
- 機能ブランチを長時間開いたままにしないでください
- リリースブランチに新機能を含めないでください
- ホットフィックスを開発にマージすることを忘れないでください
- 継続的デプロイを行う場合は Git Flow を使用しないでください
命名規則
明確な命名規則は、チームが各ブランチの目的を理解するのに役立ちます。
命名例
# Feature branches
feature/user-authentication
feature/api-integration
feature/responsive-navbar
# Release branches
release/1.0.0
release/2.1.0
release/3.0.0-beta
# Hotfix branches
hotfix/1.0.1
hotfix/2.1.3
hotfix/security-patch-3.0.1Git フローを使用する場合
✅ 次の場合に Git Flow を使用します。
- あなたが持っている 予定されているリリース (継続的な展開ではありません)
- サポート 複数のバージョン 生産中
- あなたは 素晴らしいチーム 多くの並列機能を備えた
- 安定性を得るには厳格なプロセスが必要
❌ 次の場合は Git Flow を避けてください。
- あなたがやる 継続的な展開 (GitHub フローを使用)
- あなたは 小さなチーム (3名未満)
- プロジェクトが単純またはプロトタイプである
- 1 日に複数のデプロイメント
Git Flow の代替手段
Git Flow だけがワークフローではありません。代替案は次のとおりです。
- GitHub フロー: 継続的なデプロイメントのための、よりシンプルな、メイン + 機能ブランチのみ
- GitLab フロー: Git Flow と GitHub Flow のハイブリッド、ブランチ環境
- トランクベースの開発: 全員が機能フラグを使用してメイン/トランクにコミットします
Git Flow 用ツール
Git Flow CLI をインストールする
# macOS
brew install git-flow
# Linux (Ubuntu/Debian)
sudo apt-get install git-flow
# Windows (Git Bash)
# Download da: https://github.com/petervanderdoes/gitflow-avh
# Verifica installazione
git flow version結論
Git Flow は、スケジュールされたリリースと複数のバージョンを管理するチームにとって強力なワークフローです 生産中です。その厳格な構造は規律と予測可能性をもたらしますが、それは可能性があります。 継続的なデプロイを行う単純なプロジェクトやチームにとっては過剰です。次の場合は Git Flow を選択します 安定性と構造化されたプロセスが優先事項です。
🎯 重要なポイント
- 2 つの常設ブランチ: 主要 (生産) 開発する （統合）
- 新機能の機能ブランチ
- リリースを準備するためのリリース ブランチ
- 本番環境の重大なバグに対するホットフィックス ブランチ
- 計画的なリリースや大規模なチームに最適