はじめに

ぐるなびさんが１日ごとにリリースを行う場合はGitflowを使わないという記事を書いていたので、１週間に１度リリースをしている僕の会社のGitフローについて書いてみようと思います。
「GitFlowは使わない！シンプルな「GitFeatureFlow」を紹介します」

開発の流れ

図が汚くて申し訳ございません。

featureブランチはreleaseブランチから作ります。
featureブランチで開発中のものはいつでもdevelopブランチにpushできます。
featureブランチで開発を終えたらreleaseブランチにプルリクエストします。同時にdevelopブランチにもpushします。
その週のリリース物が集まったらstagingにマージしてE2Eテストをします。
問題なければmasterにマージします。
developブランチはチームに一声かければいつでも削除して新しくreleaseブランチから作ります。

特徴

developのブランチの役割がGitflowやGitHubFlowなどとは異なります。
実験的な変更を試したり、フィードバックを貰うための環境を作ったり、プルリクエストで簡単な動作チェックなどをするためにdevelopブランチを使っています。
リリース物を集約するreleaseブランチが存在します。
GitLabFlowの考えに近いものですが、フローが複雑になるのが嫌なのでstableのリビジョンは省いてます。
pre-productionの位置付けのstagingが存在します。
E2Eテストを行います。品質確保の要です。

前提

僕の会社ではスクラム開発を行っていています。
原則、1スプリント1週間、1スプリント1リリースのサイクルです。

水曜日：（午前）リリース、（午後）スプリントプランニング
木曜日：スプリント
金曜日：スプリント
月曜日：スプリント
火曜日：（午前）スプリントレビュー・レトロスペクティブ、（午後）リリース準備、自主学習

また、ソフトウェアが動く環境として下記の環境を用意しています。

本番環境(Production)
ステージング環境(Staging)
開発環境(Develop)

環境はすべて異なるサーバー、DB、ネットワーク構成で構築しています。
master/staging/developのブランチにプッシュすると、自動的にテストとデプロイが行われます。

GitFeatureFlowとの比較

ぐるなびさんの表を元にうちのフローを評価してみました。

比較する項目	GitFeatureFlow	うちのFlow
複数案件対応	◎	◎
大規模開発向き	◎	◎
小規模開発向き	◎	◎
シンプルなフロー	○	×
リリース時期の調整	◎	△
リリース日の変更	◎	△
コンフリクト関連	△	○

あれ？GitFeatureFlowより劣っている？🤔
うちの場合はリリース日が固定なので、あまりリリース時期を調整するとか変更するとかで悩んだ事なかったよね・・・。
例外として、緊急リリースしなければならない場合はHotfix的なブランチを作成してすぐにリリースしてしまいます。
代わりにうちは下記のようなものを重要項目としてしています。

| 比較する項目 | うちのFlow |
|:----------|:----------:|:----------:|
| 開発環境で思う存分実験できる | ◎ |
| リリース計画に沿った開発物を集約できる | ◎ |
| ステージング環境で品質を確保 | ◎ |
| ステージングと同じものが本番で動いている安心感 | ◎ |

おわりに

会社ごとにいろいろなGitの使い方があるんだと知りました。うちの会社に入ってきた人は、あまりのフローの複雑さに戸惑う人も多いので、もっと簡単にしたい気持ちもあったりします。
参考になればと思います。