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とか無理..やらかしそうで怖い..」という状態でしたが、書き終えた頃には全体像を理解して恐れずに使えるくらいにはなったかなと思っています。

誤りや不適切な表現があれば、遠慮なくご指摘いただけると嬉しいです！🙇‍♀️