1つの大きなGitリポジトリまたは複数の小さなリポジトリ
私の5人の開発者チームは、6つのソリューション（別名セクション）で構成される中規模のアプリケーションを維持しています。現時点では、ソース管理にTFVCを使用しています。各ソリューションは、独自のメインブランチにあります。
Gitに移行したい。私の問題は、6つのソリューションすべてに1つのGitリポジトリを使用するか、ソリューションごとに個別のGitリポジトリを使用するかです。
私は単一のGitリポジトリを持つことに魅力を感じています。理由は次のとおりです。
- チームの複雑さを軽減します。
- 1つのコミットで、複数のソリューションに関連する変更を加えることができます（コードをあるソリューションから別のソリューションに移動するなど）。
一方、単一のGitリポジトリは、任意のソリューションへの変更が、TeamCityCIサーバー上のすべてのソリューションの新しい完全な再構築につながることを意味します。
この問題について他のチームリーダーからの洞察を探しています。
オープンソースの場合、VCSアクセスを広く世界に公開したい場合は、プロジェクトごとにリポジトリを用意する必要があります。オープンソースプロジェクトの多くの規則は、従来、プロジェクトが生成するパッケージごとにリポジトリを使用していましたが、確立された規則とパッケージに関するツールが改善されてマルチテナントリポジトリをより適切にサポートするようになるにつれて、これは変化しています。
内部作業の場合、単一のリポジトリ（またはいくつかの大きなリポジトリ）がはるかに優れています。それ以外の場合、相互作用またはリソースの共有が必要なコードベース間の一貫性を確保するなどのことを行うのは非常に困難です。現実の世界では、多くのリポジトリがあるすべての状況で、追加のリポジトリ間で不必要に作業しなければならないために発生する追加のオーバーヘッドと同期の問題に問題があることに気付きました。
注意点があります。互いに関係のないものについては、それらは喜んで別々のリポジトリに置くことができます。 Gitには、モノリポジトリに関する特定の欠陥もあります。これは、monorepoが非常にうまく機能するSVNと比較するとわかります（外部、リポジトリ全体をプルする必要がない、特定のフォルダーを取得できるなど）。シンボリックリンクを使用するなど、これらのいくつかを回避できます。
各プロジェクトを独自のリポジトリに保持し、ビルドサーバーがそれらと個別に対話できるようにします。個々のプロジェクトリポジトリをサブモジュールとして含む単一のリポジトリを作成することで、開発者の作業を簡素化し、リポジトリ間の変更の調整を容易にすることができます。そのため、開発者は大きなリポジトリ（サブモジュール参照を介してプロジェクトリポジトリを取得します）をチェックアウトし、ビルドサーバーはプロジェクトリポジトリをプルするだけです。
ソリューションごとに1つのリポジトリを使用して、方法論を現在の状態に保ちます。必要に応じて、特定のリポジトリの変更のみに基づいてビルドするようにTeamCityを構成します。私はジェンキンスがこれを行うことができることを知っています。