Gitのブランチ戦略とは？Git FlowとGitHub Flowを学ぶ

疑問

Gitのブランチ戦略にはどのようなものがあり、どのように使い分ければよいのでしょうか？Git FlowとGitHub Flowについて一緒に学んでいきましょう。

導入

Gitのブランチ戦略は、チーム開発においてコードの管理とリリースを効率的に行うための重要な手法です。適切なブランチ戦略を選択することで、開発の混乱を減らし、安定したリリースを実現できます。

本記事では、Git FlowとGitHub Flowを中心に、実践的なブランチ管理方法まで詳しく解説していきます。

解説

# developブランチからfeatureブランチを作成
git checkout develop
git pull origin develop
git checkout -b feature/new-feature

# featureブランチで作業後、developにマージ
git checkout develop
git merge --no-ff feature/new-feature
git push origin develop
git branch -d feature/new-feature

# リリース準備: developからreleaseブランチを作成
git checkout develop
git checkout -b release/1.0.0

# リリース完了: mainとdevelopにマージ
git checkout main
git merge --no-ff release/1.0.0
git tag -a v1.0.0 -m "Release version 1.0.0"
git checkout develop
git merge --no-ff release/1.0.0
git branch -d release/1.0.0

# 緊急修正: mainからhotfixブランチを作成
git checkout main
git checkout -b hotfix/critical-bug

# hotfix完了: mainとdevelopにマージ
git checkout main
git merge --no-ff hotfix/critical-bug
git tag -a v1.0.1 -m "Hotfix version 1.0.1"
git checkout develop
git merge --no-ff hotfix/critical-bug
git branch -d hotfix/critical-bug

# mainブランチからfeatureブランチを作成
git checkout main
git pull origin main
git checkout -b feature/new-feature

# 作業を進める
git add .
git commit -m "Add new feature"
git push -u origin feature/new-feature

# プルリクエストを作成（GitHub上で）
# コードレビュー後、mainブランチにマージ

# mainブランチを最新の状態に更新
git checkout main
git pull origin main

# マージされたfeatureブランチを削除
git branch -d feature/new-feature
git push origin --delete feature/new-feature

# mainブランチからfeatureブランチを作成
git checkout main
git pull origin main
git checkout -b feature/new-feature

# 作業を進める
git add .
git commit -m "Add new feature"
git push -u origin feature/new-feature

# プルリクエストでmainブランチにマージ
# マージ後、stagingブランチにマージしてステージング環境にデプロイ
git checkout staging
git pull origin staging
git merge main
git push origin staging

# 本番環境へのデプロイ
git checkout production
git pull origin production
git merge staging
git push origin production

# 新機能の開発
feature/user-authentication
feature/payment-integration
feature/dashboard-analytics

# バグ修正
fix/login-error
fix/payment-validation
fix/memory-leak

# 緊急修正
hotfix/security-patch
hotfix/critical-bug

# リリース準備
release/v1.0.0
release/v2.0.0

# その他の変更
chore/update-dependencies
chore/add-ci-config

# スコープを含む命名
feature/auth/login-page
feature/payment/stripe-integration
fix/api/error-handling

# Fast-forwardマージ（デフォルト）
git merge feature-branch

# No-fast-forwardマージ（マージコミットを作成）
git merge --no-ff feature-branch

# Squashマージ（コミットを1つにまとめる）
git merge --squash feature-branch
git commit -m "Merge feature-branch"

# マージ戦略の確認
git log --graph --oneline --all

## 変更の概要
このプルリクエストで何を変更したか簡潔に説明してください。

## 変更の理由
なぜこの変更が必要なのか説明してください。

## 変更内容
- 変更点1
- 変更点2
- 変更点3

## テスト方法
どのようにテストしたか説明してください。

## スクリーンショット（該当する場合）
UI変更の場合は、スクリーンショットを添付してください。

## チェックリスト
- [ ] コードが動作することを確認した
- [ ] テストを追加した
- [ ] ドキュメントを更新した
- [ ] コードレビューを依頼した

# 1. 最新のmainブランチを取得
git checkout main
git pull origin main

# 2. featureブランチに戻ってマージ
git checkout feature-branch
git merge main

# 3. コンフリクトが発生した場合、ファイルを確認
git status

# 4. コンフリクトを解決（エディタで編集）
# <<<<<<< HEAD
# 現在のブランチの内容
# =======
# マージするブランチの内容
# >>>>>>> main

# 5. 解決後、ファイルをステージング
git add conflicted-file.txt

# 6. マージを完了
git commit -m "Resolve merge conflicts"

# 7. リモートにプッシュ
git push origin feature-branch

# GitHubでのブランチ保護設定（Web UI）
# Settings > Branches > Add rule

# 保護するブランチ名
main

# 設定項目:
# - Require a pull request before merging
#   - Require approvals: 1以上
#   - Dismiss stale pull request approvals
# - Require status checks to pass before merging
#   - Require branches to be up to date before merging
# - Require conversation resolution before merging
# - Require signed commits
# - Require linear history
# - Include administrators
# - Restrict who can push to matching branches

# 小規模チーム（1-5人）
# 推奨: GitHub Flow
# - mainブランチ + featureブランチ
# - 継続的なデプロイ
# - シンプルなワークフロー

# 中規模チーム（5-20人）
# 推奨: GitHub Flow または GitLab Flow
# - GitHub Flow: シンプルな継続的デプロイ
# - GitLab Flow: 環境ブランチを使用
# - コードレビューの必須化

# 大規模チーム（20人以上）
# 推奨: Git Flow
# - main + develop + feature + release + hotfix
# - 複雑なリリース管理
# - 本番環境の安定性重視

# ブランチ戦略のベストプラクティス

## プルリクエスト
- [ ] 1つの明確な目的を持つ
- [ ] 200行以下の変更
- [ ] 明確な説明とテストを含む
- [ ] 関連するIssueを参照

## ブランチ管理
- [ ] 明確な命名規則に従う
- [ ] 定期的にmainブランチと同期
- [ ] マージ後はブランチを削除

## コードレビュー
- [ ] すべての変更をレビュー
- [ ] 建設的なフィードバックを提供
- [ ] 承認を得てからマージ

## コミット
- [ ] 小さなコミットを心がける
- [ ] 意味のあるコミットメッセージ
- [ ] 関連する変更をまとめる

まとめ

Gitのブランチ戦略は、チーム開発においてコードの管理とリリースを効率的に行うための重要な手法です。Git Flowは複雑なリリース管理に適し、GitHub Flowはシンプルで迅速な開発に適しています。

プロジェクトの規模と要件に応じて適切なブランチ戦略を選択し、明確な命名規則とコードレビュープロセスを確立することが重要です。小さなプルリクエストを心がけ、定期的にmainブランチと同期することで、スムーズな開発が可能になります。

実践的なプロジェクトでブランチ戦略を適用し、チームで協力して経験を積むことで、より効率的な開発プロセスを構築できます。