Git Flowのようなマージ戦略は本当にアンチパターンですか？
私の会社はGitを使用しており、独特の分岐スキームを使用しています。作業はマスターで行われ、分岐はリリース用に予約されています。イテレーションで行われたすべての作業がブランチに入る限り、これは問題なく機能しますが、重大な本番の問題が発生した場合は、作業が何らかの方法で両方のブランチに入るようにする必要があります。
最近、私たちはそれらのブランチでいくらかの「楽しみ」を持っています。これは管理上の問題であり、すべての作業がすべてのブランチに確実に組み込まれ、1つのブランチで修正された一部のバグは、誰かが指摘するまでマスターになりません。
私は Git Flow しばらく前に出くわしましたが、それが私たちの問題の解決策になると思います-リリースまで、またはずっと前までコードが浸透していません。唯一の難点は、私のリードがこの種の開発は反パターンであると述べたことです。2週間猛烈に開発し、マージの競合を解決するために3を費やしました。
私が同意するかどうかは完全にはわかりませんが、それを育てて以来、通常どおり仕事が再開されました。つい最近、いくつかの大きな問題がありました。
知りたいのですが、なぜこの種の開発スキームはアンチパターンと見なされるのでしょうか？ それは本当にアンチパターンですか？
彼は主にモデルの機能ブランチ側に言及しています。機能ブランチは何ヶ月も前からブランチが存在し、バージョン管理システムがマージしてその命を救うことができなかった昔、アンチパターンと宣言されていました。特に1週間または2週間続く機能ブランチの問題ははるかに少なくなります。その間、継続的にfromdevelopを機能ブランチにマージしている場合はなおさらです。それよりずっと長いものはまだお勧めできません。
Gitフローの機能ブランチ側を使用しない場合でも、他の部分はクリーンなマージを確実に行い、変更が正しい方向に伝播するのに役立ちます。
マージはおもしろいことです。実行頻度が低いほど、それが難しくなるほど、それを恐れる人が増えるほど、実行頻度が低くなります。
解決策は、ブランチが大きく逸脱しないようにするか、ブランチを使用しないようにすることです。
人々がこれを理解していれば、おそらくマージにそれほど問題はないでしょう。そうでなければ、ブランチは教育を受けずに良いアイデアではないかもしれません。