Gitブランチ：複数のリリースブランチがある場合の問題のマージ
複数のリリースをサポートする必要があるため、上の図と同様のgit分岐モデルに従っています。ここでの問題は、ここでfix/011の例をたくさんマージする必要があることです。3つの異なるブランチ（master、release/1.0およびrelease/2.0）をマージしています。また、master、fix/011、またはrelease/1.0からこのrelease/2.0ブランチをどこから作成するかという質問もあります。マスターから作成すると不要な機能が発生し、リリースブランチから作成するとマージのオーバーヘッドと競合が発生し、マスターにチェリーピックバックするとエラーが発生しやすくなります。
より良いアプローチはありますか？さまざまなお客様がさまざまなリリースを使用しており、小さな問題を修正するためにメジャーアップグレードを行うことを望まないことが多いため、シングルリリースブランチアプローチに従うことはできません（価格設定の側面もあります）。
Githubを使用しています。
私が見つけた1つの良いオプションは、すべてのブランチからfix（/ feature）ブランチをフォークすることです（参照： https://docs.Microsoft.com/en-us/Azure/devops/repos/git/git-branching-guidance ？view = Azure-devops＃port-changes-back-to-the-master-branch ）ですが、開発者は既存のアプローチとそれほど大きな違いはなく、複雑であると感じています。
覚えておかなければならないのは、修正をマージすると、その祖先もすべてマージされることです。そのため、コードを2.0中1.0、マージは常に1.0から2.0、そしてその逆は決してありません。つまり、修正は可能な限り最も古いブランチに作成（またはリベース）してから、2番目に古いブランチにマージし、次に3番目に古いブランチにマージする必要があるということです。通常、開発者は最先端のEdgeで作業することを好み、メンテナンスブランチを後から考えることだけを考えるため、これには多くの規律が必要です。
残念ながら、これをブランチで行うことはできません。実際、これらの赤い線のマージをまったく行うべきではありません。
リリースXがマスターからアップデートを取得しないと決めたら、そのブランチから修正をマージすることはできません。各ブランチの修正を個別に記述する必要があります。
再入力を回避するためにできることは、コードをバージョン管理されたライブラリに分割し、それらのライブラリの修正バージョンを使用するようにリリースを更新することです。うまくいけば、これによりコードの重複が減り、ライブラリの機能が時間の経過とともに変化しないことがわかります。したがって、リリース1とリリース2はどちらもライブラリv1.2を使用できます。
複数のバージョンをサポートする必要がある場合は、常にマージのオーバーヘッドがありますが、特定のバグ修正ブランチを各リリースブランチにマージする代わりに、次のことができます。
- バグのある最も低いバージョンのリリースブランチ（たとえば、release/1）からバグフィックスブランチ（たとえば、bugfix/001）を作成します。
- バグ修正ブランチをリリースブランチにマージします（バグ修正/ 001をリリース/ 1に）
- リリースブランチを次のリリースブランチにマージします（release/1をrelease/2に）
- 次のリリースブランチがある限り、「リリースブランチを次のリリースブランチにマージする」を繰り返します。
- 最新のリリースブランチをマスターにマージする
このようにして、たとえばrelease/1からいくつかのバグ修正ブランチを作成し、release/1にマージして戻すことができます。ある時点でrelease/1をマージするので、複数のマージを上位ブランチにマージする必要はありません（すべての適用済み）バグ修正）release/2へ
リリースブランチを他のリリースブランチにマージしたくない場合（たとえば、リリースブランチにタグを作成し、作業中のブランチに最新のタグが何であるかを知りたい場合）、横に修正ブランチを作成できますリリースブランチとフィックス（たとえば、fix/1）ブランチをそれぞれのリリースブランチ（release/1）と次のフィックスブランチ（fix/2）にマージします。リリースブランチからバグ修正ブランチを作成する代わりに、修正ブランチから作成します。
あなたはより良い代替案を求めているので、IMHOは トランクベースの開発（TBD） 、または少なくともそれが使用するリリースブランチ戦略を考慮する必要があります：
マージはありませんリリースブランチはどのような方向でも関係ありません。だからあなたが言及したマージの問題はありません:)
注：ここではメジャー/マルチチェンジセットマージを意味します。個々のチェンジセット（チェリーピック）マージではありません。
- リリースブランチで必要な別のブランチからの変更は個別に選択され、他の変更と同じように検証されます（他のブランチで機能するという事実）あまり意味がない、それでもブランチのコンテキストが異なるために破損を引き起こす可能性がある）
- 本当に必要な場合/必要な場合は、メジャーリリースからのマイナーリリース用のチャイルドリリースブランチや、ホットフィックスの小枝を用意することもできます。リソース、それは高価になることができます）。
これは、 分岐モデルとは に示されている方法です：
しかし、開発ブランチのユーザーには精神的なシフトが必要です。
個人的には、TBDが大規模なプロジェクトに対応できる唯一のソリューションであり、ブランチのマージは通常 Integration/Merge Hell に変換されると考えています。
特に大規模なプロジェクトの場合、少なくともマスターブランチに適切なCI/CDパイプラインを配置することは、ほぼ必須です。リリースブランチも、それぞれ1つずつ持つことでメリットを得られます。
悪い選択
ここにうまく当てはまる適切な分岐/マージ/コミット制御戦略があるとは思いません。
確かに次のことができます：
- 最も古い共通の祖先から前方に変更をマージしますが、これは本当に奇妙なコミット履歴を生成し、ある程度の規律を必要とします。
- バージョン1または2をマスターにマージして戻す必要がある場合は、チェリーピックコミットで開発のコンテキストが失われ、本当に大きな頭痛が生じます。
- 古いリリースへのパッチ適用/改善はサポートしていませんが、これはビジネスに明らかな影響を及ぼします。
分割統治
問題が痛みを伴う場合、通常、最良の戦略は、問題をより小さく管理しやすい問題に分割することです。
- プロジェクトを2つの異なる製品に分割し、それらに別々のリポジトリを提供し、バグを2回修正します。
- コードベースをリファクタリングして、一般的なコードを個別にパッチを適用できるライブラリに引き出します。
- uIを分割し、バックエンドを均質化します-2つのスキンを提供します。
ビジネスケース
なぜ別々のバージョンを維持する必要があるのですか？その答えは興味深いでしょう。
- それがお金についてであるならば、アップグレードに割引を与えて、単純化が起こるのを許すことを考慮してください。
- UIとユーザートレーニングについて。新しいUIよりも古いUIを提供できないかどうかを確認します。
- それがバックエンドデータベースなどの場合。問題を解決してみてください。移行するのは危険ですか？ DBエンジンをサポートしなくなりましたか？これらは対処でき、2番目のバージョンの必要がなくなります。
- バージョン1はバージョン2とは異なる機能のセットを提供するのですか？多分それをいくつかの一般的なライブラリに支えられた2つの製品に分割しますか？
- サポートを販売しているからですか？ （冗談ではありません）サポート料金を引き上げて、問題点を相殺してください。または、野蛮なことが少ない場合は、セキュリティや主要な製品機能に影響を与えない新機能やバグ修正の料金を引き上げてください。