【第2回】Gitブランチ戦略について調べた（後編）
最初に
前編記事は以下です。前編ではブランチ戦略の基本情報とブランチ戦略の1つのGit Flowについて紹介した。Git Flowを採用することはいくつかのメリットがあるが、CI/CDの統合では不向きであることなどが分かった。
【第1回】Gitブランチ戦略について調べた（前編）
今回の記事では、GitHub FlowやGitLab Flowの基本知識となるトランクベース開発を紹介し、その後にGitHub FlowとGitLab Flowを紹介する。最後に各ブランチ戦略を比較しポイントを整理する。
各章はWeb調査をもとに要約、整理した内容を記載している。参考にした記事は参考情報としてリンクも載せるので興味ある方はご参照ください。
基本知識
トランクベース開発
DevOpsのプラクティスの1つ。頻繁（数時間ごとなど）にmainブランチ（またはトランクと呼ばれる）にマージするバージョン管理手法。
参考情報：トランク ベース開発
参考情報：DevOps 技術: トランクベース開発
GitHub Flow
トランクベース開発をベースとするブランチ戦略の1つ。軽量なためソフトウェア開発以外の用途にも有用。GitHubの利用を前提としている。
GitHub Flowの概要
mainとfeatureの2つのブランチで管理する開発モデル。リリースごとのブランチはない。GitHub Flowは6つのフローから成る。
- 新機能を追加するときはmainブランチからfeatureブランチを作成する。
- featureブランチで変更を追加する。
- プルリクエストを作成する。
- レビュー・コメントをする。
- プルリクエストをマージする。
- featureブランチを削除する。
参考情報：GitHub Flow
GitHub Flowの特徴
1.新機能開発
- featureブランチにより独立した新機能開発が可能で進捗確認ができる。
2.バグ修正
- 新機能開発と同様。
3.リリース管理
- 本番環境はmainブランチからリリースされる。
- 環境ごとにブランチは用意しない。
- 開発環境も主にmainブランチからリリースされる。
4.CI/CDの統合
- GitHubがサポートしているため、柔軟で拡張性がある。
- 新機能や修正は直ちにmainブランチにマージされ、変更が素早く本番環境で利用できる。
5.その他
- featureブランチは一時的で、長期的に存在しない。
GitLab Flowの概要
GitHub Flowと同じくトランクベース開発をベースとするブランチ戦略の1つ。GitHub Flowとの違いはリリース管理の部分で、GitLab Flowは環境ごとにブランチを用意する。また、GitLabの利用を前提としている。フローはGitHub Flowに比較的似ているため割愛する。
参考情報：Introduction to GitLab Flow
GitLab Flowの特徴
1.新機能開発
- featureブランチにより独立した新機能開発が可能で進捗確認ができる。
2.バグ修正
- 新機能開発と同様。
3.リリース管理
- 本番環境はmainブランチからリリースされる。
- 本番環境、ステージング環境、開発環境へはそれぞれmainブランチ、stagingブランチ、developブランチからリリースされる。
4.CI/CDの統合
- GitLabがサポートしているため、柔軟で拡張性がある。
- 新機能や修正は直ちにmainブランチにマージされ、変更が素早く本番環境で利用できる。
5.その他
- ステージング環境での追加検証や試験が必要な場合はstagingブランチへもマージされる。
まとめ
調べたブランチ戦略についてそれぞれを取り入れることで得られるメリットについて整理する。
メリットが得られない場合を×としていることを除き、後は特徴をわかりやすくするため◎、〇、△の順で整理した。
| ブランチ戦略 | Git Flow | GitHub Flow | GitLab Flow | 補足 |
|---|---|---|---|---|
| 1.新機能開発 | 〇 | 〇 | 〇 | |
| 2.バグ修正 | 〇 | △ | △ | 〇：hotfixesがあるため。△：featureで代替できるため。 |
| 3.リリース管理 | ◎ | × | ◎ | |
| 4.CI/CDの統合 | × | 〇 | ◎ | |
| 5.軽量さ | × | ◎ | △ | △：GitHub Flowと比較して相対的に評価。 |
表にまとめた結果から、GitHubなどのサービスを利用できる前提であればGitHub FlowかGitLab Flowのいずれかから採択の検討をすれば良いと考える。また、その2つの判断基準については開発の規模やリリース管理をしっかり行いたいかから判断すればよいと分かった。
最後に
ブランチ戦略を調べる中でCI/CDの統合について強く結びついている印象を受けた。そのため、Gitとブランチ戦略の学習をした後はGitHubやGitLabの学習が次のアクションになると思った。個人的に何となく言葉は知っているけど手を動かしたことがないのはイシュートラッキングのため、そこについて機会があれば調べたい。
次回の記事では引き続きGitをテーマにしつつ、Gitコマンドの写経をする中で似たようなコマンドがいくつか見つかったので違いを整理できればと思う。
免責事項
内容の正確性、安全性等を保証するものでなく、何らの責任を負うものではありません。本記事内容のご利用により、万一、ご利用者様に何らかの不都合や損害が発生したとしても、何らの責任を負うものではありません。
Discussion