質問: 社内で git flow で運用してますといわれて以下の手順で運用してたのですが、別の質問でこれは git flow ではないといわれました。 たしかに master にリリースしてしばらくした後にマージする点が少し違うと思うのですが、それ以外に違う点はありますでしょうか。 > > 1. 新機能追加や修正は develop から feature や fix をきる > * (直接修正はすべて feature, fix ブランチのみで行う) > 2. ローカルで動作確認後 develop に PR レビュー OK ならマージ > * (develop には PR 経由のマージのみ) > 3. ステージング環境に develop をデプロイ > 4. 動作確認OKなら develop から release/x.x.x.x をきって本番デプロイ > * (リリースは本番デプロイ時点のスナップショット的扱い 1度きったら一切変更しない) > 5. 本番でしばらく問題なければ master に release をマージ > * マスターは常に安定動作するバージョンを維持 (develop や本番環境からは少し遅れる) > > > git flow の説明サイトもいくつか読んでみたのですが何が違うのかよくわかりません。 チームで最初に紹介されたのがこのページでしたが A successful Git branching model 自分で読んだのはこのあたりです Git-flowって何? - Qiita git-flow cheatsheet
回答: ※かなり原理によった考え方ですので、本来はプロダクトの性質やチームの状況によって柔軟に進めてください。 おそらく2点勘違いがあります。 (1)releaseブランチの扱いについて 質問には > > リリースは本番デプロイ時点のスナップショット的扱い > > > と書いていますが、参考にされているどのサイトにも 「プロダクトリリースまでの準備ブランチ」 とあります。つまりdevelopにおいておくとどんどん新しい機能が追加されてしまい全然安定化しないので releaseブランチで安定化作業を行います。 質問をみると「動作確認」というおそらくリリース前の作業があると推測されます。 であるならば「動作確認」作業前にreleaseブランチを作成して、ステージング環境にアップロードしてバグフィックスを行いましょう。それらはすべてreleaseブランチで作業を行います。 そこで動作確認がOKであれば、masterブランチに適用して本番リリースを行います。 releaseブランチをdevelopに戻すことも忘れずに! (2)masterブランチの扱いについて 質問中にある > > 本番でしばらく問題なければ master に release をマージ > > > こちらの内容も、どのサイトにも記述はなく、 releaseが安定化し実際にリリースする段階になったらまずはreleaseをmasterにマージするものです。 > > When the state of the release branch is ready to become a real > > release, some actions need to be carried out. First, the release > > branch is merged into master (since every commit on master is a new > > release by definition, remember). > > > まず最初にマージしてねと記述がありますね。 スナップショット的扱いをしたいのであればタグを切ることをおすすめします。 このあたりにタグがあります。