私の会社では、現在Subversionを使用しています。私たちのプロジェクト開発プロセスは、コードの「ライブ」ブランチ（これはライブWebサーバー上にあるものです）、小さなプロジェクトの一般的な開発ブランチで構成され、大きなプロジェクトごとに独自のブランチがあります。通常、常に少なくとも2つの大きなプロジェクトが開発中です。それらをライブブランチにマージするのは面倒ですが、さらに面倒なのは、大規模なプロジェクト1がライブになり、大規模なプロジェクト2が少し遅れてライブになり、そのマージプロセスが面倒になることです。
私がSVNで行っていることは、ライブ（つまり、発生するバグ修正など）から開発ブランチに毎日マージすることです。しかし、より大規模なプロジェクトのマージプロセスはまだ面倒であり、Gitでよりクリーンになるかどうか疑問に思っています。SVNで発生した「悪い」問題の一例として、devに小さな機能があり、それをライブにマージします。次に、ライブバックマージを実行すると、SVNはその機能を再びdevにマージしようとします（競合が発生します）。マージでそのコミットを手動で選択解除しない限り。私の理解では、Gitはコミットが開発で発生したことを知るのに十分「賢い」ので、それをマージして戻そうとはしません...しかし私の理解は間違っている可能性があります。また、Gitは、私たちがやろうとしているように、複雑なマージを自動的に処理するのに優れていると聞いています。
したがって、最初の質問は次のようになります。Gitは、私たちが行っていることに関してSVNよりも著しく優れているのでしょうか、それとも、同じ問題やヘアリーマージに遭遇する可能性が高いのでしょうか。
2番目の質問：私たちのシナリオに適した他の統合方法はありますか？特に、無差別統合についての記事を読んでいましたが、それは、同時に進行するプロジェクトが増えるほど、指数関数的に難しくなるようにも思えます。しかし、繰り返しになりますが、同時に3つ以上、通常は2つだけの大きなプロジェクトがあるとは思いません。継続的インテグレーションは、オールオアナッシングプロジェクトである傾向があるため、または部分的にプッシュされた場合にユーザーに不快感を与える可能性があるため（たとえば、最近のチェックアウトプロセスの再設計）、多くのプロジェクトではオプションではありません。 この記事は、私たちの状況にとっても良い方法論のように思われました。