同じ全体プロジェクトの一部である複数のGitリポジトリをグループ化する

サーバーコンポーネント、Webアプリコンポーネント、iOSコンポーネント、Androidコンポーネントなど、複数のコンポーネントを持つプロジェクトがあるとします。これらのコンポーネントはすべて個別のコードベースですが、疎結合（たとえば、サーバーの変更）コードでは、他のすべてのコンポーネントの変更も必要になる場合があります）

Gitでこのプロジェクトを整理する最も効率的な方法は何ですか？すべてを1つのリポジトリに配置すると、常に最新バージョンを使用できますが、1つのコンポーネントを変更し、他のコンポーネントを変更し始めると事態は非常に面倒になります。

一方、各コンポーネントを個別のリポジトリとして作成する場合、これらのリポジトリを「リンク」して、アプリのバージョン2.0にサーバーコンポーネントのバージョン1.5などが必要であることを知るにはどうすればよいでしょうか？

複数の関連するレポをより効果的に管理するために、最新のreadme（または表示されないより良いソリューション）を維持する以外に、gitに機能はありますか？

サブプロジェクトは、分散バージョン管理システム（DVCS）が開始された場所であり、解明されないとしても、確かに少し不安定になります。

Git サブモジュールとMercurial サブリポジトリは どちらもサブプロジェクトのサポートを目的としています。どちらもリリースごとに改善されています（Mercurialの古い「この機能は存在しますが、おそらく使用しないでください」という警告は、もはや前面と中央ではありません。）

それでも、マルチプロジェクトリポジトリは、すべてのユーザーが使用する機能というよりも、特殊なユースケースにとどまります。ドキュメントには、「プロジェクトのプロジェクト」の管理が2レベルの関心事であり、メタ管理が直接の単一レベルのプロジェクト管理とはわずかに異なることを明確にする多数の警告と「使用方法」指示が含まれています。その結果、世の中にははるかに少ない経験しかありません。また、「gitサブモジュールを使用しないでください！」の不足はありません。および「水銀サブレポを避ける！」コメントとブログ投稿。

サブレポに関する私自身の経験はさまざまでした。それは働いた...しかし、それはまた迷惑だった。サブプロジェクトのアイデアは気に入っていますが、実際には、より簡単に（エレガントではありませんが）大規模なオールインワンリポジトリまたはコンパニオンシブリングプロジェクトの代替案を見つけます。サブレポが主流であり、苦痛ではない日を楽しみにしていますが、まだ経験していません。

これは、サブモジュール/サブレポの管理がうまくいかないと言っているわけではありませんが、注意して行うべきものであり、事前の実験と計画を確実に行う必要があります。

Gitに焦点を合わせていることを考えると、Git サブモジュールも検討する必要があります。Gitサブツリーは、gitサブモジュールのより良い代替手段であると考える人もいます。

C＃を使用する場合、NuGetを使用できます。

各コンポーネントをライブラリにして、独自のリポジトリに保管します。セマンティックバージョニングに従ってバージョン管理する基本コンポーネントのリリースを作成します。

最後に、ビルドサーバーを使用してライブラリをNuGetパッケージにパッケージ化し、フロントエンドコンポーネント（iOS、Android）のプロジェクトでそれらのNuGetパッケージを使用します。

同じ基本的なアプローチ（バージョンとパッケージの依存関係）は他の言語でも使用できますが、それほど便利ではないかもしれません。

Gitサブモジュールを使用することはお勧めしません。理論的にはこの種の問題に使用できますが、価値があるよりも大きな手間だと感じています。

私の意見では、これは実際にどの程度結合されているかに依存します。git bisect回帰を追跡するときに自動化を実行できるのは本当に素晴らしいことですが、すべてのコミットが実行する他の依存関係の異なるバージョンに依存している場合、これは困難です。

2つの可能なオプションは、サブモジュールを備えた1つのリポジトリーまたは適切なバージョン管理プラクティスを備えた複数のリポジトリーです。

アプリのバージョン2.0にサーバーコンポーネントのバージョン1.5などが必要であることを知るために、これらのリポジトリを「リンク」するにはどうすればよいでしょうか。

これは通常、Git自体ではなく、いくつかの依存関係管理フレームワーク（Gradle、Mavenなど）のドメインです。