【GitFeatureFlow】GitFlowをやめて本番リリースが楽になった話 - Qiita

背景 サーバーサイド開発のプロジェクトでGitFlow(的な)運用を行っていたが、本番リリースの際に困ることがあったのでgitの運用フローを変えて解消したという話。 まず問題の内容から順番に書いているので、結論(新しい運用ルール)だけ知りたい人はこちら git運用フローについては、GitFlow・GitHub Flow・GitLab Flowなどが有名だがどれとも少し違うように思ったのでまとめた。 <2018/06/10追記> 新フローにも名前が欲しいと思っていたが、同じやり方を「GitFeatureFlow」と呼んでいる記事を見つけた。個人的にもしっくり来たのでこれからはこの呼称を使っていこうと思う。 cf. GitFlowは使わない！シンプルな「GitFeatureFlow」を紹介します <追記終わり> 導入プロジェクトの概要 採用するべき運用ルールはプロジェクトの条件にも依ると思うの

[Lumin]

これdevelopないのと一緒やん

[rryu]

この方法だと検証しているものとリリースしているものが違うので、そこを認識していないといつか事故る。検証環境では大丈夫だったがそれはたまたま別のブランチに入っていたものがあったからとか。

[Error401]

ここのコメントで議論されているようなことがQiita上で行われない（行いたくない）という雰囲気になっているのが、Qiitaの駄目な所

[diveintounlimit]

ひと目で「あ、これあかんやつや」って分かる図は、ある意味良いかもしれない…

[csouls]

developで検証してもええんやで。masterに検証NGがマージされなければ

[xlc]

試験するタイミングが間違ってるだけ。未検証のfeatureをdevelopにマージしちゃダメだろ。featureは個人作業の場所ではない。

[n314]

ブコメがすごい不思議だ。ブランチごとに検証通過したとして、あとで偉い人の検証で不可に変わることあるよね…？新機能リリースの広告の日付が前後したとか。環境の違い永遠に分かり合えなさそう。

[macoshita]

検証 NG なものがマージされちゃうのを前提としても、 NG なものだけ revert でいいんじゃ？他にも前提がありそう

[masatomo-m]

git-flowの思想をマトモに理解していればこれで「楽になった」とかいうのはおかしいと気付けるはず。チーム内にきちんとdeploy flowの運用設計が出来る人がいないのかな

[oakbow]

これdevelopの存在意義が分からんのだけど、何か見落としてるのかな？/マージした後に却下とかバグ発見の場合はrevertすりゃいいんじゃないかなあ。

[tofy]

“develop と master の乖離については、 develop を時々(リリース直後とか) master に reset --hard することで解決します。 すでに「常にfeatureブランチをmasterブランチから切ること」という運用をされているので、develop が forced push さ

[ni_haru]

ブコメ含めて参考になる

[ono_matope]

モチベーションは理解できたが、developとmasterがまるで別物になってしまうのが良くない。任意のfeatureブランチを検証環境にデプロイする仕組みを整えた方が建設的ではないか。

[tatsu_tora]

参考にはなった

[ktakeda47]

"master"をBASEにしてるのかな？これは確かにちょっとヘンだな。

[bopperjp]

yet another flow

[teracy_junk]

検証NGでdevelopにマージできる運用はあかんのでは…

[gabuchan]

feature/1が検証NGなのにdevelopにマージするのが問題。feature/1が検証OKになってからマージすればdevelopを健全な状態に保てるので追加のfeatureは開発しやすいし、developが健全ならmasterへのマージと本番デプロイも安心。

[zoe302]

同じようなフローを使用してるなー

[nilab]

「サーバーサイド開発のプロジェクトでGitFlow(的な)運用を行っていたが、本番リリースの際に困ることがあったのでgitの運用フローを変えて解消したという話」

[H_Yamaguchi]

これは怖い。

[tkmkg8m]

挙げられてる問題だけならNGなのをリバートするだけでいい気がするけど何か見落としてる？

[caffephilia]

新しい方、たまにdevelopとmasterくっつけないと怖いな。検証サーバが参照するブランチ（例えばcanary）を別に流して、検証に通り、リリースも決定したタイミングでf>developにマージする運用にすれば元のでも行ける気がする

[lavandin]

ソバ飯丼のコピペ思い出した。なつかしい

[Pasta-K]

なんで検証NGをmergeしてしまうんだろう。まともにstagingを用意することが出来なくて検証のためにdevelopに入れているということ? 🤔

[lalupin4]

ブランチ戦略がコンフリクトしとる。/ 検証用サーバーが一つしかないなら develop にマージすんな / マージ待ちの feature が複数あるなら検証用サーバーを用意しろ / 1台が良いという判断になっているなら git-flow をやめろ

[threetea0407]

これdevelopブランチ必要なのかな？featureブランチの内容をテスト環境にデプロイしたらいいだけの話じゃないの？

[umai_bow]

リリースの間隔が長いとコンフリクト地獄だ

[kazuki_9106]

はてブのコメントで「これはおかしいやろ」って話題になってるのに、Qiitaのコメントは一件もついてない謎。 こういう議論をすべき場所なのに何故だ。

[shiopon01]

GitFlowは決まり事が多い分、パッと見でブランチが何をやっているか分かりやすいくらいしか利点が見当たらなかった(めんどくさいし)。GitFlowもGitHub Flow両方やった感想で言うと、成果物の品質に違いはあんまりない印象

[potato4d]

GitHub Flow「っぽい何か」が生まれてdevelopの存在意義が希薄になっていてよくわからん

[Dai_Kamijo]

GitFlowをやめて本番リリースが楽になった話 — 上條　大 (@Dai_Kamijo) May 14, 2018 from Twitter https://twitter.com/Dai_Kamijo May 14, 2018 at 11:39AM via IFTTT

[vanbraam]

id:snowcrush氏と同意見.Release operation的にはGitHub flowとの違いが不明.developブランチは検証=test operationの話;重厚長大なGitFlowをやめて,極めて単純なGitHub flowに変えたらリリースが"楽"になるのは当然

[snowcrush]

ただのGithubフローだね、これ。developって検証環境専用のブランチを別に立ててるだけだし。仮に問題があるとすればブランチ運用ではなくテスト運用の話だろう。

[zetta1985]

"検証" の定義次第で捉え方が変わる

[mas-higa]

リリース用に rc1 rc2 ... って作るもんじゃないの?

[marmot1123]

featureの時点で検証せずdevelopにmergeするのがおかしいのでは……他の人も言ってるが。あるいはdevelopでNGが出た瞬間にdevelopをrevertするとか……

[hdampty7]

各featureはdevelopのbranchにする。各featureをdevelopにマージする際にプルリクを利用してレビューする。developにマージ後検証環境で動作確認。masterへマージ＆リリース。のようにすればOKかな。

[snjx]

ブクマのコメントをいろいろ参照すべし。