🐕
Gitブランチ戦略の導入検討
ブランチ戦略とは
ソフトウェア開発におけるソースコード管理するための方針です。
開発チーム内のソース修正方法やマージ方法などを決定し、ソースコード管理煩雑化に伴うデグレ・品質低下・進捗不透明を防ぐことを見込めます。
本当はもっときちんと記載するべきでしょうがまずは上記視点でおさえます。
Git のブランチ戦略
Git のブランチ戦略は３種類でベースとなる指針としては以下でよいと思われますが、プロジェクトの要件に応じたカスタマイズは必要です。
| 状況 | ブランチ戦略 |
|---|---|
| 大規模で計画的なリリースが必要な場合 | Git Flow |
| 小規模で頻繁なデプロイが必要な場合 | GitHub Flow |
| 複数環境へのデプロイが必要な場合 | GitLab Flow |
Git Flow
最も体系的で厳格なブランチ戦略です。
大規模なプロジェクトや計画的なリリースサイクルを持つプロジェクトに適してます。
ブランチ構成
| ブランチ名 | 概要 |
|---|---|
| master | プロダクションコード用の永続的なブランチ |
| develop | 開発用の永続的なブランチ |
| feature | 新機能開発用の一時的なブランチ |
| release | リリース準備用の一時的なブランチ |
| hotfix | 緊急バグ修正用の一時的なブランチ |
A successful Git branching model
そのほか
- 2020 年 3 月 5 日に追記があり、Web アプリなど継続的デプロイメントが行われる場合はより単純な GitHub flow などを採用したほうがよいことも記載されてます。
GitHub Flow
シンプルで理解しやすいワークフローです。
小規模チームや継続的デプロイメントを実践するプロジェクトに適してます。
ブランチ構成
| ブランチ名 | 概要 |
|---|---|
| main（master） | プロダクションコード用の永続的なブランチ |
| feature | 機能開発やバグ修正用の一時的なブランチ |
特徴
- Pull Request を中心としたワークフロー
- 継続的デプロイメントを前提とした設計
- main ブランチは常にデプロイ可能な状態を維持
ルール
- main ブランチは常にデプロイ可能な状態とする
- 新しい作業は必ず main ブランチから新規ブランチを作成する
- 機能追加・変更、バグ修正
- 作業用ブランチは定期的に Push する
- 早めの Pull Request 作成を推奨
- Push の理由は他のメンバーと進捗を共有するため
- Pull Request でコードレビューを行う
- コードレビュー承認後、main ブランチにマージする
- マージ前にテストを終わらせる
- レビュー承認後は素早くマージ
- main ブランチにマージ後、即時デプロイ
- 小さな変更を頻繁にリリース
GitLab Flow
Git Flow と GitHub Flow の中間的な位置づけです。
マルチ環境でのデプロイが必要なプロジェクトに適してます。
ブランチ構成
| ブランチ名 | 概要 |
|---|---|
| main | 開発用の永続的なブランチ |
| production | 本番環境用のブランチ |
| pre-production | ステージング環境用のブランチ（オプション） |
| feature | 機能開発やバグ修正用の一時的なブランチ |
特徴
- 環境ごとのブランチを用意
- production, pre-production 以外の環境が必要であれば増やしてよい
- Upstream first の原則（上流ブランチから下流ブランチへの一方通行の変更）
- 上流ブランチで承認された変更のみを下流に反映
- バグ修正は最上流のブランチに適用し、そこから下流に反映
- Issue 駆動型の開発を推奨
- main ブランチに直接プッシュしない
- マージリクエストを承認することで main ブランチに反映
Discussion