同じリポジトリ内の2つの製品に推奨されるGitブランチ戦略はありますか？
私のチームには、関連するがかなりユニークなマイクロサービスを組み込んだ大規模サービスのGitリポジトリがあります。私たちは最近、リリースブランチとデプロイメントの観点から、マイクロサービスを独自のサービスに分離することを決定しました（そのため、大規模なサービスとは独立してマイクロサービスをデプロイできます）。重要なのは、大規模なサービスとマイクロサービスの間で共有される共通コードがあるため、分離が完了していないことです。その結果、1つのソリューションと1つのリポジトリで両方のサービスを構築し続けることが提案されています。
この質問のために、マイクロサービスを独自のリポジトリに移動できない（または移動できない）と仮定します。 同じリポジトリ内に異なる「製品」の2つのリリースを持つための推奨されるGit分岐パターンはありますか？
現在、私たちは開発ブランチを持つモデルを使用しているため、各製品に独自のリリースブランチがあると、2つのリリース間でマスターと開発ブランチにマージするときに厄介なマージ競合が発生する可能性があることに注意します。
推奨される戦略は、「それをしない」です。 gitでこれを行う最もクリーンな方法は、3つのリポジトリを持つことです。
- プロジェクトA
- プロジェクトB
- 共通ライブラリ
次に、git submodule（documentation here ）を使用して、プロジェクトAとBの両方を共通ライブラリと同期させます（基本的にサブモジュールを使用すると、リポジトリ内にリポジトリを作成できます）。 Maven、Gradle、npmなどのビルドまたは依存関係管理ツールを使用している場合は、git submodule部分をスキップして、依存関係を管理するために使用できます（これにより、クリーンでエラーが発生しにくくなります）。
リポジトリを3つに分割できない場合は、3つの開発ブランチを持つ3つの別個のマスターが必要であり、変更を適用するために2つのプロジェクトのマスターに共通マスターをリベースします。この方法で何かを壊すこと（およびマージの競合が発生すること）は非常に簡単なので、これには細心の注意が必要になることに注意してください。
ソースコードとGitレベルでは、個別の分岐戦略は必要ありません。必要に応じて1つまたは両方をデプロイできるように、ビルド/デプロイソリューションを構成する必要があります。クリーンブレークを行い、これらの2つのプロジェクトを完全に分離したい場合は、別個の分岐戦略が理にかなっています。そうでない場合は、複雑さを増すことで利益が得られません。それはあなたのワークフローと誰が何をしているかに依存しますが、同じチームが両方のプロジェクトを管理し、それらが本当に関連している場合、それらを同じブランチに維持することはより良い戦略かもしれません。 2つの異なるリリースブランチが本当に必要な場合は、おそらく3つあるはずです。統合ポイントとして機能し、他の2つのブランチの基本ブランチとなるリリース共通ブランチ。