大きなプロジェクトレイアウト：複数のサブプロジェクトに新しい機能を追加する

バージョン管理管理システムで多くのコンポーネントを持つ大きなプロジェクトを管理する方法を知りたいです。

私の現在のプロジェクトには、4つの主要な部分があります。

1. ウェブ
2. サーバ
3. 管理コンソール
4. プラットホーム。

Webとサーバーの部分は、私が書いた2つのライブラリーを使用します。合計で5つのgitリポジトリと1つのmercurialリポジトリがあります。プロジェクトビルドスクリプトはプラットフォームリポジトリにあります。構築プロセス全体を自動化します。

問題は、複数のコンポーネントに影響する新しい機能を追加するときに、影響を受ける各レポジトリに対してブランチを作成する必要があることです。機能を実装します。それを元に戻します。私の直感は「何かが間違っている」です。

単一のリポジトリを作成し、そこにすべてのコンポーネントを配置する必要がありますか？その場合、分岐が簡単になると思います。または、私が今やっていることをやるだけです。その場合、各リポジトリにブランチを作成するこの問題をどのように解決しますか？

説明した状況では、複数のリポジトリを使用してもメリットは得られませんが、コストがかかります。リポジトリの古いバージョンにロールバックできず、システムが引き続き動作することを確信できます。これは、コードがリポジトリ間で密結合しているためです。ロールバック機能に対する自信がソース管理の主な利点の1つであるため、これはあなたが望んでいる状況ではありません。

ソリューションは、その中のコードの結合に基づいてリポジトリ構造を定義することです。プロジェクトコンポーネントAがプロジェクトコンポーネントBと安定したインターフェイスのみを共有する場合、それらは別々のリポジトリに配置できます。それ以外の場合は、同じリポジトリに同じ場所に配置する必要があります。よりきめ細かなリポジトリレイアウトは、より優れたファクタリングシステムアーキテクチャを反映します。

各リポジトリがスタンドアロンのプロジェクトまたはライブラリである場合、プロジェクト全体にまたがる新しい機能を追加するときに、各リポジトリに機能ブランチを作成する必要があることに本質的に問題はないと思います。スタンドアロンにすることで、それぞれを個別にバージョン管理でき、古いAPIを廃止できます。

しかし、特定のケースでは、リポジトリがコードを効果的にグループ化していないようです。あるリポジトリのコードを変更するために他のリポジトリを変更する必要がある場合（廃止は別として）、カップリングがきつすぎるか、リポジトリを再編成する必要があります。

すべてのリポジトリが実際に同じプロジェクトの一部である場合（スタンドアロンではない場合）、たぶん1つのリポジトリのみが必要です。（または、2：メインプロジェクトと、汎用/標準化された機能用のプロジェクト。）