代表的なブランチ戦略である「Git-Flow」・「GitHub-Flow」・「GitLab-Flow」の特徴とそれぞれのメリット・デメリットをまとめました。
参考
- Git-flow GitHub-flow GitLab-flowという開発フローについてまとめる
- Gitflow, GitHub flow, GitLab flow, Git Feature flow, Truncate Based Development のまとめ
- gitのブランチ運用ルールについてのご紹介
Git-Flowとは
Git-Flowとは複数のブランチを役割ごとに運用する戦略で、主に以下の6種類のブランチが使われます。
ブランチ | 役割・特徴 |
---|---|
master | 本番環境にリリースするためのブランチ。 常にリリース可能な状態を維持します。 |
develop | 開発中の主軸となるブランチ。 最新の開発状態が反映され、開発中のコードが集約されます。 |
feature | developブランチから分岐し、個別の新機能や改修作業を行うためのブランチ。 作業後、動作確認をして問題がなければ、developブランチにマージします。 |
release | リリースの準備のためのブランチ。 developブランチから分岐し、動作確認やバグ修正などの最終調整を行ったあと、masterブランチにマージします。 |
hotfix | 本番環境で発見された緊急のバグ修正を行うブランチ。 masterから分岐し、修正作業が完了したらmasterとdevelopにマージします。 |
Git-Flowの開発フロー
-
機能開発や改修作業を行う
a. developからfeatureブランチを作成
b. featureブランチで開発作業を行う -
開発作業が完了
a. featureブランチをdevelopブランチにマージ -
リリース準備
a. developブランチからreleaseブランチを作成
b. releaseブランチでバグ修正や最終調整を行う -
リリース
a. releaseブランチをmaster・developブランチにマージ
b. masterブランチをデプロイ -
本番環境でバグが発生したら
a. masterブランチからhotfixブランチを作成
b. 修正が完了したら、hotfixブランチをmaster・developにマージ
Git-Flowのメリット
- masterは原則、releaseブランチからマージされるため、履歴がシンプルで追跡しやすい
- リリース準備中もdevelopブランチでの開発を並行して行える
- 開発用とリリース準備用で別のブランチを使用することで、意図せず開発中の機能をリリースしてしまうリスクを避けられる
- リリース後の緊急のバグ修正はmasterから作成したhotfixブランチで行うため、開発中の他ブランチへの影響を考慮せず迅速に対応できる
- masterは常にリリース可能な状態を保てるため、品質が保証される
- 多くのGUIツール(SourceTreeやForkなど)がサポートしているため、視覚的に管理することができる
Git-Flowのデメリット
- 表面上は複雑なので、人によっては慣れるのに時間がかかる
- プロジェクトの運用方針によりコードレビューを行わない場合は、コードの品質は開発者に依存する
- 複雑な運用フローのため、CI/CDツールを導入する際には考慮すべき点が多く、他の開発フローと比較すると自動化ツールの恩恵を受けにくい
CI/CDツールの導入について
- 複数のブランチからのマージが発生する(特にdevelopブランチはfeature・release・hotfixからマージされる)ため、CI/CDを同時実行することにより、サーバーに負荷がかかり、動作が重くなってしまう可能性があります
- CI/CDツールが実行中のブランチには、新しい変更をマージできないことがあります。頻繁にマージが発生するgitFlowでは作業が滞る可能性があります
- パイプラインの設定が複雑になりがちで、設定ミスのリスクも懸念されます
GitHub-Flowとは
GitHub Flowは、メインブランチと作業用ブランチの2種類だけで運用する開発フローです。
ブランチ | 役割・特徴 |
---|---|
master | 本番環境にリリースするためのブランチ。 常にリリース可能な状態を維持します。 |
feature | masterブランチから分岐し、個別の新機能や改修作業を行うためのブランチ。 作業後、masterブランチにプルリクエストを送り、コードレビューを通過したらmasterにマージします。 |
GitHub-Flowの開発フロー
-
機能開発や改修作業を行う
a. masterからfeatureブランチを作成
b. featureブランチで開発作業を行う -
開発作業が完了
a. featureブランチで動作確認を行う
b. 動作確認が完了したらプルリクエストを作成 -
コードレビュー
a. 担当者にプルリクエストのレビューしてもらう
b. レビューを通過したら、featureブランチをmasterブランチにマージ -
リリース
a. masterブランチの最新状態を本番環境にデプロイ
GitHub-Flowのメリット
- シンプルなフローで理解しやすい
- コードレビューによってコードの品質を担保しやすい
- CI/CDツールを用いて細かなリリースを頻繁に行うことができる
GitHub-Flowのデメリット
- シンプルなブランチ戦略で、バージョン管理ができない
- masterブランチのみでしか確認ができない(検証環境での確認ができない)
- 開発人数が多かったり、1回のプルリクエストのボリュームが大きいと、コードレビューの負担が大きくなる
GitLab-Flow とは
GitLab-Flowではmaster、pre-production、productionの3つのブランチを主体として運用する開発フローです。
gitHub-Flowに検証用のブランチを追加したイメージです。
ブランチ | 役割・特徴 |
---|---|
master | 開発の主軸となるブランチで、新しい機能やバグ修正が統合されます。 常に最新の開発状態が反映される。 |
pre-production | ステージング環境用のブランチで、リリース前の最終確認を行う。 masterブランチから変更をマージし、ステージング環境での動作確認やテストを実施。 |
production | 本番環境にリリースするためのブランチ。 pre-productionブランチから変更をマージし、本番環境にデプロイする。 |
feature | masterブランチから分岐し、個別の新機能や改修作業を行うためのブランチ。 作業後、動作確認をして問題がなければ、masterブランチにマージします。 |
hotfix | 緊急のバグ修正を行うブランチ。 masterから分岐し、修正作業が完了したらmasterにマージする。 |
gitLab-Flowの開発フロー
-
機能開発や改修作業を行う
a. masterからfeature ブランチを作成
b. featureブランチで開発作業を行う -
開発作業が完了
a. featureブランチを master ブランチにマージ
b. コードレビューを行い、必要に応じて修正 -
ステージング環境へのデプロイ
a. masterブランチからpre-productionブランチにマージ
b. 自動または手動でpre-productionブランチをステージング環境にデプロイ
c. ステージング環境で動作確認を行う -
リリース
a. ステージング環境での確認が完了したら、 pre-productionブランチの変更をproductionブランチにマージ
b. 自動または手動でproductionブランチを本番環境にデプロイ -
本番環境でバグが発生したら
a. masterからhotfixブランチを作成
b. hotfixブランチで修正作業を行う
c. 修正が完了したら、 hotfixブランチをmasterブランチにマージし、 pre-productionブランチにマージ
d. ステージング環境で確認後、 pre-productionブランチから productionブランチにマージして本番環境にデプロイ
GitLab-Flowのメリット
- gitHub-Flow同様、運用フローがシンプルで理解しやすい
- 検証環境を経由して段階的にデプロイすることで、複数の環境で確認ができるため品質を保証しやすい
- デプロイする際のアクションが一貫しているので、CI/CDを導入しやすい
GitLab-Flowのデメリット
- hotfixブランチはmaterから作成し、通常のリリースと同様の手順を踏むためやや時間がかかる
- 手動で運用している場合は、masterに開発中・未検証のシステムが含まれる可能性があり、hotfix対応時にもそれらを考慮する必要がある。また、開発中・未検証のシステムを誤ってリリースしてしまうリスクがある
まとめ
Git-Flow、GitHub-Flow、GitLab-Flowについて調べた内容をまとめました。
記事を書き始めた時は「Gitとか無理..やらかしそうで怖い..」という状態でしたが、書き終えた頃には全体像を理解して恐れずに使えるくらいにはなったかなと思っています。
誤りや不適切な表現があれば、遠慮なくご指摘いただけると嬉しいです!🙇♀️