git-flowを採用するべきではない - Qiita

https://qiita.com/ktateish/items/76ca0130aec3be05376c

私がこれまでGitの研修講師やブランチ戦略のコンサルティングをおこなってきた経験に基づいて、この記事を書きます。

Gitのワークフローについては自転車置き場の議論になりがちであまり乗り気がしないのですが、最近少し発見があったのと、実際に多くの現場で明らかにフィットしないのに git-flow を検討したり採用したりしようとして苦労をしている様を目撃することが多いので書くことにしました。

この記事で主張する内容はタイトルの通りですが、まず前提として以下を宣言しておきます:

全てのケースに100%フィットするようなワークフローは存在しない
git-flowがフィットするケースも探せばあるかもしれない
どのようなワークフローを採用するかは最終的にはあなた（のチーム）が判断すべき

さて、 git-flow は 2010年1月「A successful Git branching model」というブログポストによってバズり、以来多くの人が参考にしてきたワークフローです。

私個人としては、その重厚なやり方が肌に合わなかったので採用したことはありませんが、美しい図とともに紹介された git-flow は当時Gitが登場してまだ数年、ワークフローについては多くの人が手探り状態だった当時においてはたくさんの人を惹きつけ、以来多数のプロジェクトで採用されてきたようです。

2022年現在においても、新規のプロジェクトや特にルール不明瞭のまま運用してきたリポジトリについて「ワークフローを整理しよう」となったときにまず挙げられるのが git-flow なのではないでしょうか。私が目撃したプロジェクトではだいたい次のようなワークフローが多かったです。

GitHub Flow風。多数派。ただし２種類あり……
- 実は明確なルールなしのゆるふわ運用（ほとんどこれ）
- ガチ勢（ごく僅か）
git-flow風（上記以外）

特に、ゆるふわ運用から「そろそろちゃんとやるか」と決意して運用方法を選定するときにgit-flowを検討・採用することが多いように思います。

しかし、 git-flow は今時のWebアプリ開発において採用するにはあまりにも重厚すぎて、すぐに改造され簡略化された git-flow「風」の別物のワークフローとして運用されるケースを多く目撃しました。また、git-flowが想定しているような比較的大きな変更を伴うリリースをする開発スタイルは、利用中のリリース＝デプロイされたバージョン1つのみで、細かい変更を高頻度にリリースするWebアプリの開発スタイルとは乖離が大きくなってきています。つまり、2022年現在ではほとんど誰も git-flow を必要としていないのです。「git-flowをベースにカスタマイズすればよい」のかもしれませんが、後述するとおり git-flow 自体、Gitの特性をあまり考慮せずに作られたワークフローのように思われるので、参考にすべきではないと思います。

英語圏の記事では、実際に git-flow を批判する内容の文書がいくつか見つかります。（邦訳はあるものの、日本発の文書は見当たりませんでした）

以下は批判的な記事というわけではありませんが、冒頭に興味深い注釈があります

Gitflow Workflow (日本語訳)

上記日本語訳の記事冒頭より引用

Gitflow とは、元来は Git ブランチを管理するための破壊的で斬新な戦略のレガシー Git ワークフローです。Gitflow の需要は落ち込み、トランクベースのワークフローが利用されるようになっています。現在ではこれが最新の継続的なソフトウェア開発のベストプラクティスおよび DevOps プラクティスと見なされています。Gitflow はまた、CI/CD と使用することも困難な場合があります。この投稿では、歴史的な目的で Gitflow の詳細をご説明します。