特別な理由なしにgit-flowを新規採用するべきではない - Qiita

私がこれまでGitの研修講師やブランチ戦略のコンサルティングをおこなってきた経験に基づいて、この記事を書きます。 Gitのワークフローについては自転車置き場の議論になりがちであまり乗り気がしないのですが、最近少し発見があったのと、実際に多くの現場で明らかにフィットしないのに git-flow を検討したり採用したりしようとして苦労をしている様を目撃することが多いので書くことにしました。 この記事で主張する内容はタイトルの通りですが、まず前提として以下を宣言しておきます: 全てのケースに100%フィットするようなワークフローは存在しない git-flowがフィットするケースも探せばあるかもしれない 例えばすでに何年もgit-flowでうまく回せてるよ、など どのようなワークフローを採用するかは最終的にはあなた（のチーム）が判断すべき さて、 git-flow は 2010年1月「A succ

[gfx]

git-flowはもともとウェブアプリ向きではないよね。パッケージを作ってリリースするアプリ（モバイルアプリなど）はgit-flowがフィットすると思うよ。

[o108minmin]

「存在意義のないmasterブランチ」説に同意。masterじゃなくてタグで良い

[iselegant]

タイトルに圧を感じるけど、「全てのケースに100%フィットするようなワークフローは存在しない」というのは経験上、同意。

[txjp]

featureブランチの開発工程の合間にdevelopをマージするコミットが挟まれていると開発過程が追いにくいので僕は嫌い。コミット間のdiffにdevelopの変更が紛れてしまう。rebaseしてほしい。

[touka_tt]

featureの開発が完了してdevelopにマージしたときにコンフリクトが発生するわけだけど、頻繁にソースコードをマージして問題を早期に発見し、差分が小さいうちに解消するというCIの考えに逆行してるのが問題だと思ってる

[tettekete37564]

全体として何をそんなに怒っているのか分からん。hotfix は master へマージして dev へ ff マージでいいのでは？rebase はローカルで行うモノだだから出てこないのは当然では？ツリーの効率よりメンバが分かりやすいのが一番

[raimon49]

A successful Git branching modelを書いた当人も後からgit-flow使うのやめていたのに、最初の図だけが日本語で紹介されたのが不幸だったように思う。git-flowみたいなGitの使い方じゃSubversionと変わらない。

[teppeis]

最初にgit flow使ったときmasterって意味あるの？ってなって誰もmaster更新しなくなった -> 事実上のgithub flow化

[n314]

結構丁寧な説明だった。webじゃなくて複数バージョンを維持する必要がある場合は、最大の成功例というかそもそもgitの目的だったlinuxを参考にすればいいと思うんだけど、何か不都合があるのかな。

[Error401]

「私個人としては、その重厚なやり方が肌に合わなかったので採用したことはありませんが」使用経験ないんですか・・・

[e_denker]

git-flowの考え方だけ頭の片隅に入れておいて、github-flowで開発を始めて、困ったら足していくくらいで良い気がする。もちろん規模感とか何の開発するかとかにもよるけど、git-flowはスタート地点としてはちょっと複雑すぎ。

[gactocat]

“自転車置き場の議論”

[yutaro1985]

個人的にも初めてgit-flowを知ったときからこのやり方は過剰だなと感じていたからやはりそうなんだろうなという感想。実際にはGitHub flowがベースにブランチの命名ルールをgit-flowに倣ってやる、くらいのケースが多いような

[doscoy_t]

> 私個人としては、その重厚なやり方が肌に合わなかったので採用したことはありません　使ったことないのに論じるだけの素人にみんな踊らされすぎ

[koogawa]

話題になっているのはこれかー / スマホアプリにはフィットすると思ってる

[Magicant]

そもそも今時流行りの「マージコミットを作らずに rebase や squash を駆使して履歴を簡素化するスタイル」と全然合はない

[kimata24]

“「A successful Git branching model」というブログポスト”

[tattyu]

せめてプレフィクスは標準機能としてGitに入れて欲しい。

[natural90000]

“存在意義のないmasterブランチ”

[KentarouTakeda]

複数環境で受け入れテスト進行しつつ機能開発も並行稼働、みたいな状況だと意図せずgit-flowとほぼ同じツリーになってたりする。つまり状況によっては役立つのだと思う。この手のは目的を理解し適度に使うべきで要はry

[queeuq]

サービスに合わせてかなりカスタマイズしたgit-flow使ってた。masterが空気はそう。

[umai_bow]

github-flowでいいよね。足の長い変更はどのみちfeature flagでやったほうがよい

[hylom]

リリースサイクルが決まっていて（月1とか隔週とか）、次リリースでのbugfixとその次のリリースでの新機能と将来リリース予定の機能を並列で開発するみたいなシーンだとgit-flowはフィットする感じ

[bouzuya]

個人的な観測範囲だと master と topic と tag で十分なことがほとんどだ。

[xKxAxKx]

“全てのケースに100%フィットするようなワークフローは存在しない”まあ、これに尽きるし、なんとやくそれっぽいゆるふわな感じでも問題なく運用できてるんならそれでいいんじゃね、って思う。

[NOV1975]

「比較的大きな変更を伴うリリースをする開発スタイルは～細かい変更を高頻度にリリースするWebアプリの開発スタイルとは乖離」から「つまり、2022年現在ではほとんど誰も git-flow を必要としていない」は飛躍だろ

[ghostbass]

次回リリース分がちゃんとテストされてるならブランチいらない

[pwatermark]

「実装着手はするけどリリースするかはわからない」機能はどうハンドリングすればいいんだろうね、とかいろんなケースがあるんで、結局ケースバイケースで最適化せざるを得ない 採用するかどうかも含めてね

[Makeneko]

なるほど、これが炎上狙いの宣伝か。

[ken39arg]

まあ、書いてあるけどケースバイケース。webアプリでシングルリポジトリならgithub flow、リリースを伴うアプリはgit flow風、リリースを伴うアプリのバックエンドwebアプリはミックス。 まあ、臨機応変ですね

[iww]

なんでもかんでもmasterにぶっこめばいいんだよ！

[otihateten3510]

この話何回目？

[xlc]

私がGit-flowを使っているのはSourceTreeにUIがあったから。まあでも満足してるよ。npm パッケージを開発するには十分だ。何かを批判するならその問題点と解決方法を示さなきゃただのFUDだね。

[kobito19]

github flow出たとき既に言及されていたかと

[hayashikousun]

git-flowを否定している割には，その根拠である「git-flow の要改善点」の章は大雑把に済ませるんだ。

[new3]

Waterfall/Agileと同じで万能薬・銀の弾丸はないのと一緒で適材適所で効く薬・弾丸を過剰に咎めたりタイトル主語デカで煽るのはどうかと思う。Webアプリにgit-flowが向かないのは概ね同意。

[ducktoon]

masterだけでOK

[cowbee]

git-flowがだめなのはわかったけど、じゃあどういうやり方が良いのかを例示してほしい。ありそうな運用事例をいくつかpicしてさ。フレームワーク的なのgit−flowとgithub-flowしかしらん