このカリキュラムでは、実務で役立つGitのブランチ運用戦略とワークフロー設計について学びます。
Gitフロー、GitHubフロー、Trunk-Based Developmentといった代表的なワークフローの違いを理解し、プロジェクトに最適な運用を選べる力を養います。
また、コンフリクトを回避するためのルールや、チーム全体で統一感を持って運用するための命名規則も解説します。
🧩 1. Gitの代表的なワークフローと特徴
✅ Gitフロー（Git Flow）
- 特徴:
ブランチを「機能」「リリース」「ホットフィックス」など用途別に分ける運用方法。 - 利点:
長期プロジェクトやリリース管理に向いている。 - 欠点:
ブランチが多くなり、運用が複雑になることがある。 - 主なブランチ:
main（安定版）develop（開発版）feature/*（機能開発用）release/*（リリース準備用）hotfix/*（緊急修正用）
✅ GitHubフロー（GitHub Flow）
- 特徴:
mainブランチを中心としたシンプルなブランチ運用。Pull Request（PR）ベースで開発を進める。 - 利点:
シンプルで小規模なチームやアジャイル開発に最適。 - 欠点:
リリース管理が弱く、長期プロジェクトには不向き。 - 主なブランチ:
main（安定版）feature/*（機能開発用、PR単位で管理）
✅ Trunk-Based Development（トランクベース開発）
- 特徴:
main（トランク）ブランチに対して直接または短命なブランチで頻繁にマージする手法。 - 利点:
デプロイが高速で、CI/CDパイプラインとの相性が良い。 - 欠点:
高度なCI/CD環境が必要で、コンフリクト管理のスキルが求められる。 - 主なブランチ:
main（トランク）- 短期間の
feature/*（数日以内にマージ）
🛡️ 2. コンフリクトを回避するための運用ルール
✅ 1. こまめなプルとプッシュを徹底する
git pull origin mainを定期的に実行して最新状態を保つ。
✅ 2. PRレビュー時に「差分」を小さく保つ
- 1つのPRは1つの目的に絞る（例：バグ修正と機能追加を同時にしない）。
✅ 3. CI/CDを活用して事前検証を行う
- 自動テストとリンターをPR作成時に実行する。
✅ 4. リベース運用を活用する（Trunk-Based向け）
- マージ前に
git rebaseで履歴を整理し、無駄なコミットを減らす。
🏷️ 3. チーム全体でのブランチ命名規則
チーム内で統一することで、ブランチの目的が一目でわかるようにします。
| ブランチタイプ | 命名規則例 | 説明 |
|---|---|---|
| 機能開発（Feature） | feature/issue-123-login-ui | 課題番号や目的を含める |
| バグ修正（Bugfix） | bugfix/issue-456-fix-login | バグの原因をわかりやすく示す |
| リリース準備 | release/v1.2.0 | バージョン名を明記する |
| 緊急対応（Hotfix） | hotfix/issue-789-critical | 緊急度が伝わる名前をつける |
| ドキュメント更新 | docs/update-readme | 作業内容が一目でわかる名前にする |
💡 4. 実務で使えるブランチ戦略の選び方
| 開発スタイル | おすすめワークフロー |
|---|---|
| 長期的な製品開発 | Gitフロー（Git Flow） |
| アジャイル・スクラム開発 | GitHubフロー（GitHub Flow） |
| マイクロサービス開発 | Trunk-Based Development |
| CI/CD中心の高速開発 | Trunk-Based Development |
📌 まとめ
チーム全体でわかりやすいブランチ命名規則を定め、運用の一貫性を保つ。
Gitフロー、GitHubフロー、Trunk-Based Developmentの違いを理解し、状況に応じて選べるようにする。
コンフリクトを回避するための運用ルールを徹底する。
