Mavenおよび複数のGitリポジトリーの操作
私たちは最近、ほとんどのコードが単一のリポジトリにあるSVNからgitに移行しました。ほとんどのプロジェクトは独自のリポジトリ（そのうちの約70）にあります。このJavaソースから約12の異なるアプリをビルドします。これらのアプリはすべて* nixサーバーで実行されます。ビルドにはmavenとnexusを使用します。多くの人は、機能に触れたときに機能の開発に苦労しています複数のリポジトリです。ここにいくつかの課題があります。
開発者は各リポジトリを個別にブランチする必要があります。追跡をより難しくしないようにするために、1つの機能のすべてのブランチに同じ名前を使用します。
各リポジトリのアーティファクトの更新されたバージョンを指すように、すべてのリポジトリのpomを更新する必要があります。複数の人が同じブランチで作業している場合、他のpomの変更をマージすることがたくさんあります。リポジトリの変更をコミットすると、アーティファクトの名前が「-SNAPSHOT」に変更されます。これはmore pomの更新を意味します。
変更を正しい順序でプッシュする必要があります。そうしないと、自動ビルドが失敗します。たとえば、リポジトリAはリポジトリBへの変更に依存します。リポBがビルドおよびデプロイされる前にリポAがプッシュされた場合、リポAはビルドされません。
機能をレビューする人は、複数のリポジトリの変更を確認する必要があります。
機能がそのブランチから、たとえばマスターにマージされるとき、Oneは変更されたすべてのリポジトリを記憶する必要があります。
ほとんどモノレポのアプローチに切り替えるのが最善のようですが、いくつかの欠点があります：
Mavenを使用してコードベース全体を構築するには、非常に時間がかかります。 （なぜmavenがmakeのようになり、変更されたものや依存関係が変更されたものだけをビルドすることができないのですか？）
各プッシュは、1つのリポジトリのアーティファクトのビルドとテストだけでなく、多数のビルドと多くのユニットテストを開始します。
一般に1つまたは2つのリポジトリで作業する開発者は、この新しいマルチリポジトリの世界を好み、変更に抵抗します。
私はgitサブモジュールとサブツリーを調べましたが、これらはseemでは解決できません（Google Repoについては不明）。私たちの一部は、「mu」のようなツールを使用して支援しています。開発者がpomでバージョンを維持し、リポジトリ全体の変更を追跡するのに役立つツールキットがあれば、すばらしいでしょう。
この種の環境での開発を容易にするために使用する一連の手順またはツールがあるかどうかをお知らせください。
直接的な答えではないかもしれませんが、「病気」というよりは症状だと感じています。
もしそうなら、主な問題は機能が非常に多くの異なるプロジェクトに触れることを意味するということだと思います。私たちは理想的な世界に住んでいるわけではないことを知っていますが、おそらく技術的な詳細を脇に置き、さまざまなプロジェクトの「低結合/高結合」を増やすことは興味深い目標かもしれません。
複数のプロジェクトが緊密に結合していて、常に一緒になっている場合は、それらを共通のリポジトリにまとめます。コードの大きなチャンクが比較的独立したライブラリとして抽出できる場合は、それを行います。
おそらく最も実用的なアプローチは、「リポジトリ内の各小さなプロジェクト」でも「すべてを備えた巨大なモノレポ」でもありませんが、比較的独立したプロジェクトがリポジトリ内に留まる一方で、密接に関連するプロジェクトがリポジトリ内にまとめられるというものです。