Git Flowのようなマージ戦略は本当にアンチパターンですか？

私の会社はGitを使用しており、独特の分岐スキームを使用しています-作業はマスターで行われ、分岐はリリース用に予約されています。これは、反復で行われたすべての作業がブランチに行われる限り正常に機能しますが、重大な生産上の問題が発生した場合、作業が何らかの方法で両方のブランチに行われるようにする必要があります。

最近、私たちはそれらのブランチで「楽しい」ことをしてきました。これは管理上の頭痛の種であり、すべての作業がすべてのブランチに反映され、1つのブランチで修正された一部のバグは、誰かが指摘するまでマスターになりません。

しばらく前にGit Flowに出会いましたが、それが私たちの問題の解決策だと感じています-コードがリリースまで浸透していないか、ずっと下に浸透していません。唯一の問題は、私のリードがこの種の開発はアンチパターンであると述べていることです。つまり、2週間にわたって猛烈に開発し、マージの競合を解決するために3を費やしました。

同意するかどうかは定かではありませんが、それを育ててから、仕事は通常のように再開しました。ごく最近になって、これに関していくつかの大きな問題がありました。

私は知りたい-なぜこの種の開発スキームはアンチパターンと見なされるのですか？ で、それは本当にアンチパターン？

彼は主にモデルの機能ブランチ側について言及しています。機能ブランチは、かなり前にブランチが数か月間続き、バージョン管理システムをマージして命を救うことができなかったときにアンチパターンとして宣言されました。週または2最後の特徴の枝は、あなたが継続的にマージしている場合は特に、非常に少数の問題を抱えているから、 developその時間中に機能ブランチに。それよりはるかに長いものはまだお勧めできません。

gitフローの機能ブランチ側を使用しない場合でも、他の部分はクリーンなマージを取得し、変更が正しい方向に反映されるようにするのに役立ちます。

マージはおもしろいことです-実行頻度が低いほど難しくなり、難しくなるほど、それを恐れる人が多くなり、実行頻度が低くなります。

解決策は、ブランチの逸脱を許可しないか、ブランチを使用しないことです。

人々がこれを理解していれば、おそらくマージにそれほど問題はないでしょう。そうでない場合、ブランチは教育なしでは良いアイデアではないかもしれません。