私たちのアプリはマイクロサービスアーキテクチャに組み込まれており、1つのサービスと1つのリポジトリです。多くの企業がこの慣行に従っているので、私たちはモノレポを作成すべきかどうかを模索しています。モノ対メニーの長所と短所についてはたくさんの議論があります。両方のオプションからいくつかの短所を持たせるための代替案を見つけたい場合は、gitサブモジュールを使用して「似たような」モノ構造を提供する必要がありますか?
はい、サブモジュールが善/悪であるという議論はたくさんありますが、私はサブモジュールを間違って使用していると思う傾向があります。ハンマーで釘を打つように、名前が似ているという理由だけで、欠点はありません。
それらを使用する際に考慮すべきいくつかの事柄:
それらはそれらの間およびスーパープロジェクト間で完全に分離されています。サブモジュールで行われたコミットのスーパープロジェクトには詳細な履歴はなく、それを更新したものだけです。
サブモジュールでコミットを行うときは、別のリポジトリにあるため、プッシュする必要があります。そうしないで、スーパープロジェクトに移動してサブモジュールを更新すると、プッシュされなかったコミットへの参照が表示されます。そして、これはさらに多くの問題と混乱につながります。
これらは私が頻繁に見つけた状況の例であり、人々はそれらについて不満を言っていますが、私はこれらを短所とは見なしません。プロジェクトに適しているかどうかを判断するために知っておく必要があることだけです。
モジュールのように、別のプロジェクトが埋め込まれているプロジェクトで使用していました。これらは両方とも別々に開発されており、モジュールを新しいバージョンに更新したり、互換性の理由から特定のバージョンに維持したりすることがあります。誰がモジュールに取り組んでいるのか、何を作ったのかを知る必要はありません。彼らがいつ新しいバージョンをリリースしたか、何かを修正したかを知りたいだけです。
多分もっと経験のある人がそれを共有するでしょう、私たちは確かにそれを必要としています。