これはスケールアップの問題のようです。通常、リポジトリには 1 つのプロジェクトが含まれます。1 つのプロジェクトのいくつかの部分で 1 つのユーティリティ モジュールを共有する場合がありますが、小規模なプロジェクトの場合、ユーティリティ モジュールを独自のエンティティとして分離することを検討するほど規模が大きくありません。ただし、ユーティリティ モジュールが「大きく」なったり、それを共有するいくつかの独立したエンティティを分離する必要がある場合は、独自の (バージョン管理された) モジュールにする必要があります。
私のアプローチは、関与するコードの量に応じて、別々のリポジトリを使用することです。主要なリファクタリングですが、追加されたタスクが何を意味するのかわかりません。私が最初に行うことは、共有リソースをスタンドアロン リポジトリに作成し、そのリリースを (バージョン固有の) 依存関係として各プラットフォーム ビルドに組み込むことです。これにより、各プラットフォームでの開発が単一の共有リソース バージョンから分離されます。共有プロジェクトに変更を加えるたびに、とにかくすべてのプラットフォームをテストする必要があります。これで、明確な境界線ができました。次に、そこにある各プロジェクトを一度に 1 つずつ独自のリポジトリにすることができます。
複数のプラットフォームにまたがるプロジェクトの「共有リリース」が必要な場合は、そのためのビルド コードのルートである「プロジェクト」が必要です。そのコードにも共有リポジトリを使用することを検討するかもしれませんが、それは共有コードのリリースをプロジェクトのリリースに結合します。コードがこのレベルの複雑さに達した場合、ビルド コードを格納する「メタ プロジェクト」専用の別のリポジトリが必要になる可能性があります。非常に大規模なプロジェクト グループを扱う場合を除き、複数のプロジェクトのビルドをすべて 1 つのリポジトリに格納して、共通のコードを共有することができます。再び同じ問題が発生しますが、規模が小さいため、単一のリポジトリで機能します。これはすべて、ある程度の自動テストを想定していることに注意してください:)
マルチモジュール プロジェクトでの私の経験は、perl と Java の使用から得ています。perl では、CPAN から多くの独立した共有モジュールを使用するのが標準です。Java では、モジュラー依存関係は Apache Ivy または Maven を使用して処理できます。私は、会社のトップレベルのメタプロジェクトと各製品の個別のプロジェクト (会社のメタプロジェクトに依存) を持つ環境で Maven を使用しました。各プロジェクトは、必要なことを自由に行うことができました。2 つ以上のプロジェクト間で共有するために 1 つのプロジェクトからエスカレートされたコードは、独自のプロジェクトになります。1 つの特に大規模なプロジェクトは、最終的にいくつかのプロジェクトに分割され、すべて独自の「メタ プロジェクト」から継承されました。この種の階層的な依存関係を処理することは、Maven と Ivy が行うように構築されていることです。Jenkins/Hudson を統合サーバーとして使用し、プロジェクト間のビルドを毎晩自動的にチェックしました (誰もテストの作成を怠っていないと仮定して...)。かつて、会社全体のウェブサイトを変更する必要がありました。問題ありません。会社のメタ プロジェクトで一度変更すると、すべてのプロジェクトの新しいリリースで自動的に取得されました。